vfs: enable userspace to reset damaged file storage

Jane Chu has taken an interest in trying to fix the pmem poison recovery
story on Linux.  Since I sort of had a half-baked patchset that seems to
contain some elements of what the reviewers of her patchset wanted, I'm
releasing this reworked version to see if it has any traction.

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 user
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.

v2: change the name to zeroinit, add an explicit fallocate mode, and
    support regular block devices for non-dax files
v3: ignore holes and handle unwritten extents, instead of considering
    them a failure case
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmFNJ+oACgkQ+H93GTRK
tOvryA/+NrV62KYEUDbl3ny73VPVrT0sQ2iLc32LDibnsWQMB89THfNbgc1j/AFY
mSbFXVQ/h4VMJMgI3jHOHsk39cqlDQc8RE/2BShChAK+jkU1oRNgG2bFgZrLLxl4
AspvZuWP0+obY2rx0RV5bTWrz3OZvo4UlHs16sYnRJEaLohDB83YTSoO/8rCp8OA
0i/Wwe8LyX1KoxqLCxxMOuJdWCxxd45wrHgtX/HNtRKbv7dZyEG8ugrt7/Qj4T0f
L3hpDPObrAywaLO7J9kzA/HEoButjnKCNwstUeN3Q+RclpruLZ3f1n06vk9FMAIr
JIHL62oMVJiRRR+CJAkF5oJaqs7WexFayEvuuyG4OS5ilI6mko0po+3GxfCMzrMe
8hvtTp0xBfNAsMdp7DDRDEFcebE0mLLU2iQ9hbaMk4Ucmj05udfmWuU6LVJqYeGa
/TuoJu6ibCjdJP2Dgpf5EujKHi5T+nGPbZNW0ak+wsJeGmjodJZjVZSsrSu5+UWI
F0vWkkehk7EBLeMSj4opqeE6+DAKblbheb7naKLV3swtWsd8Y/iWN0J6TTTAl0Tv
7O54pzBjS9GOlBwMQWb9dkTwq4x5W0q4+JFryvoflvBmCzsyhpIW5PNGC92EYbrU
xoa43r3qiBWoBn2lZr9qVmgOemf3KiE9wBM2AChDN+NgOvS9Ng0=
=OtNu
-----END PGP SIGNATURE-----