From: Dave Chinner <david@fromorbit.com>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: xfs@oss.sgi.com
Subject: Re: [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test
Date: Tue, 13 May 2014 10:54:57 +1000 [thread overview]
Message-ID: <20140513005457.GY5421@dastard> (raw)
In-Reply-To: <20140512203505.16f73ef8@tlielax.poochiereds.net>
On Mon, May 12, 2014 at 08:35:05PM -0400, Jeff Layton wrote:
> On Tue, 13 May 2014 08:58:45 +1000
> Dave Chinner <david@fromorbit.com> wrote:
>
> > On Mon, May 12, 2014 at 11:06:29AM -0400, Jeff Layton wrote:
> > > This patchset does some general cleanup of the locktest binary, adds
> > > some infrastructure to allow testing F_GETLK requests, and adds a new
> > > F_GETLK test to the pile.
> > >
> > > The main impetus here is a regression that I caused in F_GETLK handling
> > > for v3.15. The patch is making its way to Linus now, but I want to be
> > > sure that it doesn't regress in the future.
> >
> > So do these changes cause locktest to fail on older kernels? i.e.
> > does changing the test cause the locktest tests to fail where
> > previously they passed? If so, we're going to have to make this a
> > little more complex...
> >
>
> I haven't tested on much in the way of older kernels, but I wouldn't
> expect it to cause any problems. The only behavior change that should
> be introduced is the F_GETLK test, and older kernels should pass that
> just fine (modulo v3.15 which has a regression that should be patched
> soon). The rest of the changes are just cleanups, and shouldn't
> introduce any behavioral changes.
Ok, I wasn't sure if it was adding a test that never worked, or
whether it was checking for a recent regression. If it's a recent
regression, then there's no problem with the change. Thanks! :)
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-05-13 0:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-12 15:06 [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test Jeff Layton
2014-05-12 15:06 ` [xfstests PATCH 1/4] locktest: don't assume that F_OPEN should use O_RDWR Jeff Layton
2014-05-12 15:06 ` [xfstests PATCH 2/4] locktest: set f_fd to INVALID_HANDLE on close Jeff Layton
2014-05-12 15:06 ` [xfstests PATCH 3/4] locktest: consolidate do_lock and do_unlock, and add ability to F_GETLK Jeff Layton
2014-05-12 15:06 ` [xfstests PATCH 4/4] locktest: add a F_GETLK vs. openmode test Jeff Layton
2014-05-12 22:58 ` [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test Dave Chinner
2014-05-13 0:35 ` Jeff Layton
2014-05-13 0:54 ` Dave Chinner [this message]
2014-05-13 1:00 ` Dave Chinner
2014-05-13 1:13 ` Jeff Layton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140513005457.GY5421@dastard \
--to=david@fromorbit.com \
--cc=jlayton@poochiereds.net \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox