tag name | refcount-cow-domain-6.1_2022-10-27 (b8bc751a49d66b82e28cbc965c692613518655b6) |
tag date | 2022-10-27 10:10:15 -0700 |
tagged by | Darrick J. Wong <djwong@kernel.org> |
tagged object | commit 686b1013f7... |
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.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmNau3cACgkQ+H93GTRK
tOtlrQ/+MNg6XMKRnvcc4VIh+dabogkeEvGQaaD38QeAnKQZf0MrTGRSlpE2kiSe
jHSwAcCLjovX/BaIzE+O43fIsr3AcSNSDZelVCU/Wr4xYH77Dx+e82Jdt3pu6jfz
c0cILQS6yc83M20QZ+Nlr35MNWqz5RMikFMC5a6br305fOEVNMB1XphposocnBGB
HHbxxsV3zpKB55Azqj32jzNQGXKkJY6gb8DfIBzVRHvzRSOHen8eBjurTglE3u0J
fS+a/ZtCp+/bc/+lWOZMaswnov1L4YFUEDy6rcYItAEkcwmtAGWnB5OgTPSH7YDy
bj2czcwbQwRygfWZ7h3ukv1ylEMb1PCs5vRZ/XJcBZwsdS8dlE0wmNuMTGZqsA1Y
/6reqSA1Uf3Jayh3p1e3mssReTWAbOwBpD/4zuTwj0gDHcvPdiOo29Y2AhyA8Mv8
LP90qrairN6P1BVKiUKdCjIkKWujenT7zQvbJMNv0hnVGZFNe62TI6xRFlpRRv80
vGJLsr8TMG9d9BevO/gmwlqwazfGYT1DhVQdYCj6JaAc/DiZutyy+C5mRfW8IWoW
HbGrr/gjCGOVAYu9sc5dWtTI4AWifdmxcxH8SBu7dnjD7P6pKowwj43BZmCbArkl
VNuzSil0s9cvCpWZozcAfblOh/l9m0J/yq3VQpWI0sIKdB+DL6Y=
=pLs+
-----END PGP SIGNATURE-----