[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131017144044.GA3605@thunk.org>
Date: Thu, 17 Oct 2013 10:40:44 -0400
From: Theodore Ts'o <tytso@....edu>
To: Lukáš Czerner <lczerner@...hat.com>
Cc: Eryu Guan <guaneryu@...il.com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: don't cache out of order extents
On Thu, Oct 17, 2013 at 03:44:35PM +0200, Lukáš Czerner wrote:
>
> 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.
Ah, I see what's going wrong. __read_extent_tree_block() calls
__ext4_ext_check() which is supposed to validate that extent tree
block is valid. The __ext4_ext_check() function calls
ext4_valid_extent_entries() which is supposed to validate the
individual entries in the extent. However, it is not checking to make
sure there are no overlapping extents. We should add that check to
ext4_valid_extent_entries(); that way, we will call ext4_error_inode()
to mark the file system as corrupted.
Eryu's patch, or something like it, will still be needed so that in
the case of errors=countinue, we don't end up calling BUG_ON().
Thanks for finding this!
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists