linux-ext4 - Re: [PATCH] e2fsck: Check for cases where EOFBLOCKS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20100512014403.GZ18762@thunk.org>
Date:	Tue, 11 May 2010 21:44:03 -0400
From:	tytso@....edu
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] e2fsck: Check for cases where EOFBLOCKS_FL is
 unnecessarily set

On Tue, May 11, 2010 at 08:10:06PM -0500, Eric Sandeen wrote:
> tytso@....edu wrote:
> > On Tue, May 11, 2010 at 05:06:43PM -0500, Eric Sandeen wrote:
> >> Theodore Ts'o wrote:
> >>> Some kernels will crash if EOFBLOCKS_FL is set when it is it not
> >> Is there a kernel fix to go with this, then?
> > 
> > There will be; Dmitry sent a patch in the ext4 patch a while back.
> > 
> > http://patchwork.ozlabs.org/patch/50469/
> > 
> > The fix to prevent the crash is tiny.  The rest of the patch I need to
> > review more carefully....  I'll get to it RSN.
> 
> Ok sorry, I didn't put 2 & 2 together, there.  :)
> 
> Thanks for the reminder,

To be clear, the fix to prevent the crash is:

		EXT4_ERROR_INODE(inode,
	     			"eh->eh_entries == 0 ee_block %d",
 				ex->ee_block);

to:

		EXT4_ERROR_INODE(inode,
				"eh->eh_entries == 0, iblock = %u"
				iblock);

(this is the quick fix that we dropped into our production kernels,
anyway; the problem is that ex is NULL, which means instead of marking
the file system as needing repair, we Oops the system instead.)

I just haven't had the time to analyze the rest of the patch yet.

One of the things I've been considering is whether we should be trying
to test for this failure at all.  Is there a downside if EOFBLOCKS_FL
is set when it shouldn't matter?  Should we simply not try to check
for the case?  Or if we do check, should we just clear the flag and
print a warning?  The other side of the argument is if this is wrong,
then either we have a kernel bug (see the first patch) or we had a
hardware error, in which case something else might be wrong and maybe
we should force a file system check.

						- 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