linux-ext4 - Re: [PATCH] ext4: add fallocate mode blocking for debugging purposes

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: <20140415233039.GR4456@thunk.org>
Date:	Tue, 15 Apr 2014 19:30:39 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Lukáš Czerner <lczerner@...hat.com>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	Namjae Jeon <linkinjeon@...il.com>
Subject: Re: [PATCH] ext4: add fallocate mode blocking for debugging purposes

On Tue, Apr 15, 2014 at 05:32:43PM -0500, Eric Sandeen wrote:
> > I also had a sneaking suspicion that we might have a similar issue
> > with the INSERT RANGE patches which are coming down the pike, and so
> > having a general way of also being able INSERT RANGE if to be able to
> > quickly determine whether a potential bug was caused by INSERT RANGE
> > or some other pending changes might also be useful.
> 
> Also: I'd humbly suggest just not merging those until they pass stringent
> tests like fsx & fsstress...
> 
> Adding a pre-emptive knob to turn them off post-merge when they turn
> out to be broken sounds backwards to me...

Having learned from COLLAPSE RANGE, I agree.  The fact that we didn't
have full testing during the whole development cycle was unfortunate.
And we got lucky with the renameat patches, since I wasn't able to get
tha testing done because the xfstests commits didn't get merged until
*after* the they renameat commits got merged, and also because I
didn't notice that the i386 system call wasn't wired up when I was
doing my manual "just before I push to Linus" testing.

I plan on insisting that INSERT RANGE support being in the VFS, and be
fully enabled, and that we have full INSERT RANGE testing into
xfstests, during the development cycle.  Some of the work that I've
been doing with kvm-xfstests and why I created a github tytso/xfstests
git tree is specifically to make sure things go much more smoothly
this time around.  (That way, if there is some new fs feature patch,
such as COLLAPSE RANGE or renameat(2) where the tests are still being
refined for xfstests inclusion, we can still have something we can all
use on an interim basis during the development cycle.)

However, with all of this being said, while new feature patches such
sa INSERT RANGE are cooking in the ext4.git tree, so that multiple
developers *can* do that testing, having a knob to turn the feature on
and off without having to do a kernel recompile is convenient.

Cheers,

						- 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