Re: [Ext2-devel] [RFC 0/13] extents and 48bit ext3

[Theodore Tso <tytso@mit.edu>]

On Wed, Jun 14, 2006 at 05:28:31PM -0700, Barry K. Nathan wrote:
> BTW, I actually have a test filesystem here (an e2image from an actual
> filesystem I encountered once) that used to cause e2fsck 1.36/1.37 to
> segfault. Strangely, more ancient versions (like what ships in Red Hat
> 7.2) were able to repair it without segfaulting. In a few days, once
> other stuff calms down for me, I need to revisit that and see if the
> bug still exists with 1.39.

Please try it with 1.39; if it still crashes, let me know --- I treat
any filesystem corruptions that causes e2fsck to crash or which e2fsck
can't fix in a single pass to be a bug.  I'm guessing though that this
was probably this bug which was fixed right after 1.38 released (some
distributions did have the fix, but it's in the mainline e2fsprogs
starting with 1.39):

2005-07-04  Theodore Ts'o  <tytso@mit.edu>

	* pass2.c (e2fsck_process_bad_inode): Fixed bug which could cause
		e2fsck to core dump if a disconnected inode contained an
		extended attribute.  This was actually caused by two bugs.
		The first bug is that if the inode has been fully fixed
		up, the code will attempt to remove the inode from the
		inode_bad_map without checking to see if this bitmap is
		present.  Since it is cleared at the end of pass 2, if
		e2fsck_process_bad_inode is called in pass 4 (as it is for
		disconnected inodes), this would result in a core dump.
		This bug was mostly hidden by a second bug, which caused
		e2fsck_process_bad_inode() to consider all inodes without
		an extended attribute to be not fixed.  (Addresses Debian
		Bug: #316736)

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/