On Fri, Jun 29, 2018 at 01:02:17PM -0400, Wen Xu wrote: > Hi Dave, > > Is the patch for this issue available online?...I would like to have a look. Uh.... there were multiple problems found by this one fuzz case, generating a few patches. I /think/ with one exception they'll all be in -rc3 if you want to retest. --D > Thanks, > Wen > > On Mon, Jun 4, 2018 at 3:02 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > On Mon, Jun 04, 2018 at 02:22:27PM +1000, Dave Chinner wrote: > >> On Sun, Jun 03, 2018 at 10:07:52PM -0400, Wen Xu wrote: > >> But, yeah, xfs_db tells me the by-size freespace btree is full of > >> crap, but the by-cnt tree is completely empty (i.e. corrupt) so > >> allocation should definitely be failing long before if gets anywhere > >> near returning an allocated block. > > > > Running a debug kernel assert fails in extent allocation setup for > > writeback, tripping over a bad extent alignment. The superblock > > has an invalid stripe alignment/width setup, which I've fixed. > > The extent size hint on the inode also has an invalid alignment (not > > a multiple of block size), which the inode verifiers will now catch, > > such as this: > > > > XFS (loop0): Metadata corruption detected at xfs_inode_validate_extsize+0xe5/0x110, inode 0x6d5 dinode > > XFS (loop0): Unmount and run xfs_repair > > XFS (loop0): First 128 bytes of corrupted metadata buffer: > > .... > > > > And the alignment assert has now gone away. Now there's an assert > > like this: > > > > XFS: Assertion failed: *len > 0, file: fs/xfs/xfs_extent_busy.c, line: 344 > > Call Trace: > > xfs_extent_busy_trim+0x243/0x250 > > xfs_alloc_ag_vextent_exact+0xc3/0x3b0 > > xfs_alloc_ag_vextent+0x1c9/0x330 > > xfs_alloc_vextent+0x56a/0x870 > > xfs_ialloc_ag_alloc+0x160/0x6f0 > > xfs_dialloc+0x116/0x270 > > xfs_ialloc+0x5c/0x5e0 > > xfs_dir_ialloc+0x6a/0x260 > > xfs_create+0x418/0x670 > > xfs_generic_create+0x1f6/0x2c0 > > vfs_create+0xf9/0x180 > > do_mknodat+0x1f9/0x210 > > do_syscall_64+0x5a/0x180 > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > > > I'm pretty sure this is because there are bogus extent records in > > the free space tree - pretty sure we can catch them on lookup > > via a change to ->init_key_from_rec() to validate the record before > > letting them be used. > > > > Cheers, > > > > Dave. > > -- > > Dave Chinner > > david@xxxxxxxxxxxxx > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
