summaryrefslogtreecommitdiff
tag namerefcount-cow-domain-6.1_2022-10-27 (b8bc751a49d66b82e28cbc965c692613518655b6)
tag date2022-10-27 10:10:15 -0700
tagged byDarrick J. Wong <djwong@kernel.org>
tagged objectcommit 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-----