linux-ext4 - Re: [PATCH 0/6 v2] Introduce FALLOC_FL_ZERO

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: <20140317132901.GA2773@thunk.org>
Date:	Mon, 17 Mar 2014 09:29:01 -0400
From:	tytso@....edu
To:	Lukáš Czerner <lczerner@...hat.com>@thunk.org
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 0/6 v2] Introduce FALLOC_FL_ZERO_RANGE flag for fallocate

On Mon, Mar 17, 2014 at 01:50:46PM +0100, Lukáš Czerner wrote:
> > Running the tests with the dev2 branch, which includes all of the
> > ext4-specific ZERO_RANGE patches, we see a regression with shared/243
> > with 4k and 1k block sizes (as well as 4k in no-journal mode):
> 
> Oh, right. This fails because the test really should be deprecated
> since we already removed the check in e2fsck - see e2fsprogs commit
> 010dc7b90d97b93907cbf57b3b44f1c1cad234f6.
> 
> In this patch I removed setting the EXT4_INODE_EOFBLOCKS, however I
> forgot the mention that in the description. Sorry about that.

I'm not sure how removing setting the EXT4_INODE_EOFBLOCKS flag would
result in shared/243 failing in this particular way.  The EOFBLOCKS
flag never influenced how the userspace-visible behavior of the
kernel; it only set a flag which told e2fsck that it was OK to have
blocks mapped beyond i_size. 

So removing EOFBLOCKS could potentially cause false positives by
e2fsck for e2fsprogs previous to 1.42.2 (or which do not have the
above mentioned commit pulled on).  That's the main reason to keep
support for setting EOFBLOCKS in the kernel --- to avoid causing user
help desk reports if they try using a newer kernel w/o updating the
version of e2fsprogs on their enterprise kernel distro (not that users
_ever_ upgrade the kernel on their own ;-).

But I'm not sure how this would cause the xfstests failure detailed
below?  And how would just updating the commit description deal with
the fact that shared/243 is failing?

    	      				- 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