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]

Date:	Mon, 17 Mar 2014 16:10:52 +0100 (CET)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	tytso@....edu
cc:	Lukáš Czerner <lczerner@...hat.com>@thunk.org,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 0/6 v2] Introduce FALLOC_FL_ZERO_RANGE flag for
 fallocate

On Mon, 17 Mar 2014, tytso@....edu wrote:

> Date: Mon, 17 Mar 2014 09:29:01 -0400
> From: tytso@....edu
> To: =?utf-8?B?THVrw6HFoSBDemVybmVyIDxsY3plcm5lckByZWRoYXQuY29tPg==?=@...nk.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. 

Yes, shared/243 is actually looking at the file system using debugfs
trying to figure out whether this flag is set or not. And that is
what is failing.

See the 243.full output:

Test 1: Fallocate 40960 bytes and write 4096 bytes (buffered io).
EOFBLOCK_FL bit is not set.
Error: Current bit state incorrect.

However I am not really sure why is this in shared since this is
only useful for ext4.

> 
> 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 ;-).

I believe that we're not very consistent with that anyway. That was
part of the reason why we got rid of it in e2fsck. However I agree
that this might cause additional problems. So it might be better to
just keep this in kernel for now...

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

See above. If we decide to remote the EXT4_INODE_EOFBLOCKS from
kernel then this tests has to go as well.

Btw. I am not able to call in for the ext4 call today, sorry.

Thanks!
-Lukas

> 
>     	      				- Ted
>