linux-ext4 - Re: buggy 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 19 Aug 2010 12:03:17 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	"Ted Ts'o" <tytso@....edu>
CC:	Andreas Dilger <adilger@...ger.ca>, linux-ext4@...r.kernel.org
Subject: Re: buggy EOFBLOCKS_FL handling

Ted Ts'o wrote:
> On Wed, Aug 18, 2010 at 11:13:00PM -0600, Andreas Dilger wrote:
>> On 2010-08-18, at 21:01, Theodore Ts'o wrote:
>>> It looks like how we handle the EOFBLOCKS_FL flag is buggy.  This means
>>> that when we fallocate a file to have 128k using the KEEP_SIZE flag, and
>>> then write exactly 128k, the EOFBLOCKS_FL isn't getting cleared
>>> correctly.
>>>
>>> This is bad, because e2fsck will then complain about that inode.  If you
>>> have a large number of inodes that are written with fallocate using
>>> KEEP_SIZE, and then fill them up to their expected size, e2fsck will
>>> potentially complain about a _huge_ number of inodes.
>> Probably e2fsck also shouldn't complain if EOFBLOCKS_FL is set, but
>> the i_size is within the range implied by i_blocks.
> 
> My current thinking is to have an EOFBLOCKS_relaxed mode setting in
> /etc/e2fsck.conf which controls whether we test for this case or not.
> Technically it *is* an error, but if there are file systems with a
> large number of files in this state, running e2fsck could take a
> ***very*** long time (potentially, hours longer than would otherwise
> be expected).  Hopefully once the bug fix gets pushed out, eventually
> we'll be able to turn this feature off.  (Where eventually might be a
> year or two, given that it's probably too late to get this fixed in
> RHEL 6.  :-( )

Oh it can get fixed during rhel6's lifetime, certainly.  :)

Regarding a conf file setting, I'd really rather not have another knob
that is non-obvious to the user.

Maybe e2fsck could tally these and after I dunno, 10 or 20 or so, ask
whether it should keep flagging them or just go into "yes" mode for
the rest of the inodes with that problem?

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