xfs: improve runtime refcountbt corruption detection

Fuzz testing of the refcount btree demonstrated a weakness in validation
of refcount btree records during normal runtime.  The idea of using the
upper bit of the rc_startblock field to separate the refcount records
into one group for shared space and another for CoW staging extents was
added at the last minute.  The incore struct left this bit encoded in
the upper bit of the startblock field, which makes it all too easy for
arithmetic operations to overflow if we don't detect the cowflag
properly.

When I ran a norepair fuzz tester, I was able to crash the kernel on one
of these accidental overflows by fuzzing a key record in a node block,
which broke lookups.  To fix the problem, make the domain (shared/cow) a
separate field in the incore record.

Unfortunately, a customer also hit this once in production.  Due to bugs
in the kernel running on the VM host, writes to the disk image would
occasionally be lost.  Given sufficient memory pressure on the VM guest,
a refcountbt xfs_buf could be reclaimed and later reloaded from the
stale copy on the virtual disk.  The stale disk contents were a refcount
btree leaf block full of records for the wrong domain, and this caused
an infinite loop in the guest VM.

v2: actually include the refcount adjust loop invariant checking patch;
    move the deferred refcount continuation checks earlier in the series;
    break up the megapatch into smaller pieces; fix an uninitialized list
    error.
v3: in the continuation check patch, verify the per-ag extent before
    converting it to a fsblock

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmNf8LoACgkQ+H93GTRK
tOu3Aw//Q14hrj8im673xcFvRdviPIsaGZWMrNsDG6gcnnWxOyDWcx3TkzzWQsNT
82C7urLUIEScYdjNC0G03FVLIROPVGRgaHSXHK1ldQLCjN/63Gzx2Mo5zd6eiroZ
0RJZtVTr19zQtIwvIDxXKGO/9dJpdDDTJxgtlW8BV2Xr2uBEdPQd4dcGLBiJM/cH
A/oGOeZHgXlBRFDu9HYzpZRPoOmz0KPxmobSEQF3f131J0jXWFyx5z8qnCGI0BEh
sNutyY+J77pIkbd3T4tIBZABvehUOcHQbsgET4yAKM6mw80XOiGfAyLL/4bMuBTb
HBTJwJ8EIm3ibpzutTRUf/z8sIlr4SQJ4+fnEyY40LvcNaF1THF1DxqNJYSSpwSb
MNXn6X2f5QRCCNHErAE3VpQUNT8mSRTmKKjJu6aYm9m4JpNrHZ6GedF390D3Uuwl
fNuOGN02fOhtL94XrvCdmDO+lchQ1PBN9/K7ii2b/mmja45CzxzM4y06ZT75ishX
Gq8ljh50GIjRnf1GAOoOcaPTFd+G+/UAW3cbr/+XA+0Fd7UNkDOY/JQmYR282rtz
vkebnvmpZqUlzpmbtp0G+izk0gY0GIe1widPEq67zBB1kCqTnWSoOU8vPul/Ng6n
HZAY/+35tuiCQnyp1JHH3KXQ7YOGMTbx9AQmxeifucXoc1CTMMw=
=PiZA
-----END PGP SIGNATURE-----