> On Jun 4, 2018, at 12:22 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > On Sun, Jun 03, 2018 at 10:07:52PM -0400, Wen Xu wrote: >> Hi Dave, >> >> Very strange. >> >> I checkout v4.17-rc7 of >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ >> and merge with for-next of >> https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/ to make the >> kernel build. > > The last commit from the for-next tree I have is: > > d25522f10cfa xfs: repair superblocks > > Does that match what you merged? Ah it seems not… Considering the commit log (https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/log/?h=for-next), The last commit here is fs: use ->is_partially_uptodate in page_cache_seek_hole_data > >> d1dabff17081af94c9604c5fdddd0de7 20.img >> mounting 20.img and running poc.c on mounted folder still gives me >> nullptr access. >> >> [ 1381.524410] XFS (loop0): Mounting V4 Filesystem >> [ 1381.524484] XFS (loop0): Log size 864 blocks too small, minimum >> size is 942 blocks >> [ 1381.524487] XFS (loop0): Log size out of supported range. >> [ 1381.525728] XFS (loop0): Continuing onwards, but if log hangs are >> experienced then please report this message in the bug report. >> [ 1381.533754] XFS (loop0): Ending clean mount >> [ 1388.369552] XFS (loop0): xfs_buf_find: daddr 0x7fb28 out of range, EOFS 0x8000 > > So, somehow, it's getting a block beyond EOF being allocated out of > the free space tree. So what we have here is an uncaught corrupt > freespace record.... > > <sigh> > > $ sudo xfs_repair -n -f xfs.img > Phase 1 - find and verify superblock... > bad primary superblock - inconsistent filesystem geometry in > realtime filesystem component !!! > > attempting to find secondary superblock... > ...Sorry, could not find valid secondary superblock > Exiting now. > $ > > Please use a filesystem with at least 2 AGs as the basis of your > fuzzing in future. > > 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. > > Ok, I just worked out why I haven't been able to reproduce the > issue: you have no error checking in your test code, so I get no > indication that it fails to run correctly when run as a user. > > Alright, lets start this whole thing again. > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx I see. Yeah, my test code is a bit scratchy…I will make a new seed image w/ at least 2ag for my fuzzing later. Thanks, Wen -- 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
