Re: Questions about XFS abnormal img mount test

["Darrick J. Wong" <darrick.wong@oracle.com>]

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.
>