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: <20140416000634.GT15995@dastard>
Date:	Wed, 16 Apr 2014 10:06:35 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Eric Sandeen <sandeen@...hat.com>,
	Lukáš Czerner <lczerner@...hat.com>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	Namjae Jeon <linkinjeon@...il.com>, xfs@....sgi.com
Subject: Re: [PATCH] ext4: add fallocate mode blocking for debugging purposes

[added xfs@....sgi.com]

On Tue, Apr 15, 2014 at 07:30:39PM -0400, Theodore Ts'o wrote:
> 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 asked for renameat2 tests long before inclusion occurred. The fact
is that we can't co-ordinate xfstests inclusion for a feature that
we don't even know is going to be included until someone sends Linus
a pull request....

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

There wasn't a problem with the timing of xfstests inclusion - the
problem was with the fact we didn't have sufficient QA coverage in
xfstests when the initial upstream kernel commits occurred.  This
time around, the difference will be that this time we'll have fsx
and fsstress coverage *before* kernel support is added, and I've
already asked for that:

http://oss.sgi.com/archives/xfs/2014-04/msg00121.html

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

Ted, this looks and sounds like you're preparing to fork xfstests.
Why?  What's the problem with working upstream on test development
and refinement like everyone else does?

This thread is a demonstration of how avoiding upstream interaction
results in nasty hacks being proposed. If you asked the question on
the xfs mailing list of how to avoid various fsstress/fsx
operations, we woul dhave told you that using FSSTRESS_AVOID and
adding an equivalent FSX_AVOID to xfstests is all that is needed.
i.e. we already have partial infrastructure support for what you
need in xfstests and it would be about 30 minutes work to add
FSX_AVOID....

Is that fast enough for you?

Indeed, we could also use similar env vars to ensure various
_requires_* checks fail and to populate FSSTRESS_AVOID/FSX_AVOID
automatically and so tests that require this functionality are not
run.

IOWs, it's in your best interests to work with upstream to add the
functionality you require to xfstests. History tells us that forking
development into private repositories has never worked out well for
anyone, so I'd really, really like you to *at least try* to work
with upstream as your primary test development environment....

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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