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] [day] [month] [year] [list]
Date:   Mon, 15 May 2017 14:31:26 +0200
From:   Jan Kara <jack@...e.cz>
To:     Eryu Guan <eguan@...hat.com>
Cc:     Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.cz>,
        fstests@...r.kernel.org, linux-ext4@...r.kernel.org,
        linux-xfs@...r.kernel.org
Subject: Re: [PATCH] generic/285: Add more SEEK_HOLE tests

On Sun 14-05-17 01:26:21, Eryu Guan wrote:
> On Sat, May 13, 2017 at 09:06:57AM +1000, Dave Chinner wrote:
> > On Fri, May 12, 2017 at 04:04:43PM +0800, Eryu Guan wrote:
> > > On Thu, May 11, 2017 at 06:48:09PM +0200, Jan Kara wrote:
> > > > Add tests for bugs found in ext4 & xfs SEEK_HOLE implementations
> > > > fixed by following patches:
> > > > 
> > > > xfs: Fix missed holes in SEEK_HOLE implementation
> > > > ext4: Fix SEEK_HOLE
> > > > 
> > > > Signed-off-by: Jan Kara <jack@...e.cz>
> > > 
> > > This will cause ext4 and xfs start to fail with current linus tree and
> > > appear as a new regression. So we usually don't add new tests to
> > > existing cases.
> > > 
> > > But seek_sanity_test.c deals with different SEEK_DATA/HOLE implentations
> > > nicely, which would be a bit tricky to do in a new test by shell, and it
> > > has all the infrastructures for new tests like this. So I think I'd
> > > prefer merging this patch as is, and document the false regression alert
> > > in release announce email.
> > 
> > Make the new tests optional (i.e. on a cli switch) and add a new
> > xfstest that runs them? Old test remains unchanged, doesn't fail,
> > new test covers the new tests, will fail on old kernels (which is ok
> > for new tests).
> 
> Yeah, this should work and looks a better solution to me. This avoids
> regressing generic/285 again when adding another new test in future,
> future tests could just follow this path too. Thanks for the suggestion!
> 
> Jan, could you please update the patch and, as suggested by Dave, make
> it a new test? I can do it too if you like.

Yeah, Dave's idea looks good. I'll work on it and send an updated version.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ