[PATCH 06/31] e2fsck: clear i_block[] when there are too many bad mappings on a special inode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



If we decide to clear a special inode because of bad mappings, we need
to zero the i_block array.  The clearing routine depends on setting
i_links_count to zero to keep us from re-checking the block maps,
but that field isn't checked for special inodes.  Therefore, if we
haven't erased the mappings, check_blocks will restart fsck and fsck
will try to check the blocks again, leading to an infinite loop.

Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
---
 e2fsck/pass1.c |    8 ++++++++
 1 file changed, 8 insertions(+)


diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
index 5f6e1dc..a861177 100644
--- a/e2fsck/pass1.c
+++ b/e2fsck/pass1.c
@@ -2862,6 +2862,14 @@ static void check_blocks(e2fsck_t ctx, struct problem_context *pctx,
 	}
 
 	if (pb.clear) {
+		/*
+		 * If a special inode has such rotten block mappings that we
+		 * want to clear the whole inode, be sure to actually zap
+		 * the block maps because i_links_count isn't checked for
+		 * special inodes, and we'll end up right back here.
+		 */
+		if (ino < EXT2_FIRST_INODE(fs->super))
+			memset(inode->i_block, 0, sizeof(inode->i_block));
 		e2fsck_clear_inode(ctx, ino, inode, E2F_FLAG_RESTART,
 				   "check_blocks");
 		return;

--
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



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux