On 2020/2/11 9:15, Dave Chinner wrote: > On Mon, Feb 10, 2020 at 11:02:08AM +0800, zhengbin (A) wrote: >> ### question >> We recently used fuzz(hydra) to test 4.19 stable XFS and automatically generate tmp.img (XFS v5 format, but some metadata is wrong) > So you create impossible situations in the on-disk format, then > recalculate the CRC to make appear valid to the filesystem? > >> Test as follows: >> mount tmp.img tmpdir >> cp file tmpdir >> sync --> stuck >> >> ### cause analysis >> This is because tmp.img (only 1 AG) has some problems. Using xfs_repair detect information as follows: > Please use at least 2 AGs for your fuzzer images. There's no point > in testing single AG filesystems because: > a) they are not supported Maybe we can add a check in mount? If there is only 1 AG, refuse to mount? > b) there is no redundant information in the filesysetm to > be able to detect a vast range of potential corruptions. > >> agf_freeblks 0, counted 3224 in ag 0 >> agf_longest 536874136, counted 3224 in ag 0 >> sb_fdblocks 613, counted 3228 > So the AGF verifier is missing these checks: > > a) agf_longest < agf_freeblks > b) agf_freeblks < sb_dblocks / sb_agcount > c) agf_freeblks < sb_fdblocks b is not ok, ie: disk is 10G, mkfs.xfs -d agsize=3G, so there will be 4 AG, while the last AG is 1G. sb_dblocks is 10G, while the first AG's agf_freeblks is 3G > 10G/4=2.5G > > and probably some other things as well. Can you please add these > checks to xfs_agf_verify() (and any other obvious bounds tests that > are missing) and submit the patch for inclusion? I will send a patch > Cheers, > > Dave.
