vfs: enable userspace to reset damaged file storage

Our current "advice" to people using persistent memory and FSDAX who
wish to recover upon receipt of a media error (aka 'hwpoison') event
from ACPI is to punch-hole that part of the file and then pwrite it,
which will magically cause the pmem to be reinitialized and the poison
to be cleared.

Punching doesn't make any sense at all -- the (re)allocation on pwrite
does not permit the caller to specify where to find blocks, which means
that we might not get the same pmem back.  This pushes the user farther
away from the goal of reinitializing poisoned memory and leads to
complaints about unnecessary file fragmentation.

AFAICT, the only reason why the "punch and write" dance works at all is
that the XFS and ext4 currently call blkdev_issue_zeroout when
allocating pmem ahead of a write call.  Even a regular overwrite won't
clear the poison, because dax_direct_access is smart enough to bail out
on poisoned pmem, but not smart enough to clear it.  To be fair, that
function maps pages and has no idea what kinds of reads and writes the
caller might want to perform.

Therefore, clean up this whole mess by creating a dax_zeroinit_range
function that callers can use on poisoned persistent memory to reset the
contents of the persistent memory to a known state (all zeroes) and
clear any lingering poison state that might be lingering in the memory
controllers.  Create a new fallocate mode to trigger this functionality,
then wire up XFS and ext4 to use it.  For good measure, wire it up to
traditional storage if the storage has a fast way to zero LBA contents,
since we assume that those LBAs won't hit old media errors.

v2: change the name to zeroinit, add an explicit fallocate mode, and
    support regular block devices for non-dax files
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmFFR1IACgkQ+H93GTRK
tOuKrw//SlY4s0jj3tHNlOW0I51OSFitS9+/PEDeiirSZqdEEU1wF84v/OEASlRD
/OkJpcSN5M9iDNK2sl33u0Y9brnJmJDs5oUCPFt89P6Gfupm+Y235wYM5ib0YBHs
PGOXDWMg79OFCaxh+adaUCEWuTd+x6RpBO5z3fvwZQ5pG3BPD/Umk//MvgcgZid5
0O/rBhFuQvPzB9MHQx78WhmsY5JGq3AY8yqAZS06il4jDaMYJGs8nmBeisak+0gb
1UWCbuUG3p4Q6Avlpo2/5etTvgTM1H4GRgM/J1aoXvCRn/9K37vqCjibMx4oB+M6
6xo9ijCdEXnrVANIlEp4eV9Glskd9ZzBrNezxkNi0381sBj7OmgNJDaCKf/5FaI5
805TWMv7n09b+jB8k33RgGZHR4OupxR+LgF5Vh5/ESsCT6/0ANTICSmfvJTwQ0FR
89s43wCSJFXg4TUqvatA6Cr1mheuDWRbaN0Fy6nUagzOS6A/hNOn98Yg7lh7vNzC
87hYOgsVPOnZbtsA1eO8amuL0CtlMckpZlW+pY0TcN/XSAbyCzHFL5We/VStwKln
e32ZhDuJHfw+/n6XKFsDPSKeNrsIt64tHoX8wYeXeVvWlCyp4nax4dCPwAtmWp19
2PZu0A5Hvj3oLfEZsbnV6/N0yWODLDUnJWkdQa1OwaODDnmDZ3o=
=QT5Z
-----END PGP SIGNATURE-----