On Thu, Oct 17, 2013 at 03:44:35PM +0200, Lukáš Czerner wrote: > On Thu, 17 Oct 2013, Eryu Guan wrote: > > > Date: Thu, 17 Oct 2013 17:27:53 +0800 > > From: Eryu Guan <guaneryu@xxxxxxxxx> > > To: linux-ext4@xxxxxxxxxxxxxxx > > Cc: Eryu Guan <guaneryu@xxxxxxxxx>, Theodore Ts'o <tytso@xxxxxxx> > > Subject: [PATCH] ext4: don't cache out of order extents > > > > A corrupted ext4 may have out of order leaf extents, i.e. > > > > extent: lblk 0--1023, len 1024, pblk 9217, flags: LEAF UNINIT > > extent: lblk 1000--2047, len 1024, pblk 10241, flags: LEAF UNINIT > > ^^^^ overlap with previous extent > > > > Reading such extent could hit BUG_ON() in ext4_es_cache_extent(). > > > > BUG_ON(end < lblk); > > > > The problem is that __read_extent_tree_block() tries to cache holes as > > well but assumes 'lblk' is greater than 'prev' and passes underflowed > > length to ext4_es_cache_extent(). > > > > I hit this when fuzz testing ext4, and am able to reproduce it by > > modifying the on-disk extent by hand. > > > > Ran xfstests on patched ext4 and no regression. > > So what will happen with the file system with this patch when > presented with such corruption ? > > It seems to me that ext4_es_cache_extent() will happily skip this > extent because it will find that this particular offset is already > in the tree. Hence we'll have a gap in the status tree which really > should not be there and I suspect that something bad will happen. > > I think that we should deal with this corruption immediately when we > spot it there, not just hide it. Yes, agreed, we should validate the extent not cover the corruption as Ted pointed out. Don't know why I didn't think about it more in the first place.. Thanks! Eryu Guan -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
