On Thu, Feb 13, 2020 at 04:33:38PM +0800, zhengbin (A) wrote: > > 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? No, that will break existing users. Single AG filesystems exist in a weird gray area where they're not supported but they're not explicitly prohibited either. --D > > 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. >
