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]

Message-ID: <20100819144432.GA23345@thunk.org>
Date:	Thu, 19 Aug 2010 10:44:32 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: buggy EOFBLOCKS_FL handling

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.  :-( )

	   	    	    	      - 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