[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140801181153.12496.71297.stgit@birch.djwong.org>
Date: Fri, 01 Aug 2014 11:11:53 -0700
From: "Darrick J. Wong" <darrick.wong@...cle.com>
To: tytso@....edu, darrick.wong@...cle.com
Cc: linux-ext4@...r.kernel.org
Subject: [PATCH 02/19] e2fsck: never free critical metadata blocks in the
block found map
From: Darrick J. Wong <darrick.wong@...cle.com>
Don't allow critical metadata blocks to be marked free in the block
found map. This can theoretically happen on an FS where a first
inode's ETB/indirect map block is in the inode table, the first inode
is itself unclonable (and thus gets deleted) and there are enough
crosslinked files before and after the first inode to use up all the
free blocks during pass 1b.
(I do actually have a test FS image but it's 256M and it proved very
difficult to craft a bite-sized test case that actually hit this bug.)
Signed-off-by: Darrick J. Wong <darrick.wong@...cle.com>
---
e2fsck/pass1.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
index 26fe60c..e7a6acd 100644
--- a/e2fsck/pass1.c
+++ b/e2fsck/pass1.c
@@ -3356,6 +3356,13 @@ static void e2fsck_block_alloc_stats(ext2_filsys fs, blk64_t blk, int inuse)
{
e2fsck_t ctx = (e2fsck_t) fs->priv_data;
+ /* Never free a critical metadata block */
+ if (ctx->block_found_map &&
+ ctx->block_metadata_map &&
+ inuse < 0 &&
+ ext2fs_test_block_bitmap2(ctx->block_metadata_map, blk))
+ return;
+
if (ctx->block_found_map) {
if (inuse > 0)
ext2fs_mark_block_bitmap2(ctx->block_found_map, blk);
--
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