From: Eric Biggers <ebiggers3@gmail.com>
To: keyrings@vger.kernel.org
Subject: Re: [LTP] [PATCH 0/2] ltp: update add_key tests for nonempty NULL payload fix
Date: Tue, 06 Jun 2017 17:04:25 +0000 [thread overview]
Message-ID: <20170606170425.GA88445@gmail.com> (raw)
In-Reply-To: <20170606114416.GA5208@rei>
Hi Cyril,
On Tue, Jun 06, 2017 at 01:55:52PM +0200, Cyril Hrubis wrote:
> Hi!
> > (The reason I'm not simply changing the add_key02 test is that I don't want it
> > to appear as a regression on old kernels. I'm not sure exactly how this kind of
> > thing is typically handled in LTP, though.)
>
> What exactly do you mean by a regression here? The fact that it may
> crash older kernels? That is pretty much fine, when test fails/kernel
> crashes manual intervention is required and one of the first things you
> do is git log for the test.
>
When I had tried updating existing tests in xfstests to test more cases, I was
told it shouldn't be done because then the test would start failing on some
systems as a result of the test change, rather than as a result of a kernel
regression. So it would be more difficult to figure out what caused the test
regression.
Personally, I don't align quite as strongly with that viewpoint (and maybe you
and the other LTP developers don't either) because this can, after all, only be
a problem in cases where the test suite is upgraded, and furthermore if a test
fails it's helpful to 'git log' the test anyway.
Would you suggest I simply update add_key02 instead?
Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers3@gmail.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 0/2] ltp: update add_key tests for nonempty NULL payload fix
Date: Tue, 6 Jun 2017 10:04:25 -0700 [thread overview]
Message-ID: <20170606170425.GA88445@gmail.com> (raw)
In-Reply-To: <20170606114416.GA5208@rei>
Hi Cyril,
On Tue, Jun 06, 2017 at 01:55:52PM +0200, Cyril Hrubis wrote:
> Hi!
> > (The reason I'm not simply changing the add_key02 test is that I don't want it
> > to appear as a regression on old kernels. I'm not sure exactly how this kind of
> > thing is typically handled in LTP, though.)
>
> What exactly do you mean by a regression here? The fact that it may
> crash older kernels? That is pretty much fine, when test fails/kernel
> crashes manual intervention is required and one of the first things you
> do is git log for the test.
>
When I had tried updating existing tests in xfstests to test more cases, I was
told it shouldn't be done because then the test would start failing on some
systems as a result of the test change, rather than as a result of a kernel
regression. So it would be more difficult to figure out what caused the test
regression.
Personally, I don't align quite as strongly with that viewpoint (and maybe you
and the other LTP developers don't either) because this can, after all, only be
a problem in cases where the test suite is upgraded, and furthermore if a test
fails it's helpful to 'git log' the test anyway.
Would you suggest I simply update add_key02 instead?
Eric
next prev parent reply other threads:[~2017-06-06 17:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-06 11:55 [LTP] [PATCH 0/2] ltp: update add_key tests for nonempty NULL payload fix Cyril Hrubis
2017-06-06 11:55 ` Cyril Hrubis
2017-06-06 17:04 ` Eric Biggers [this message]
2017-06-06 17:04 ` Eric Biggers
2017-06-07 13:51 ` Cyril Hrubis
2017-06-07 13:51 ` Cyril Hrubis
-- strict thread matches above, loose matches on Subject: below --
2017-06-06 12:06 [LTP] [PATCH 2/2] syscalls/add_key03: add test for NULL payload with nonzero length Cyril Hrubis
2017-06-06 12:06 ` Cyril Hrubis
2017-06-06 17:06 ` Eric Biggers
2017-06-06 17:06 ` Eric Biggers
2017-06-05 17:48 Eric Biggers
2017-06-05 17:48 ` [LTP] " Eric Biggers
2017-06-05 17:48 [PATCH 1/2] syscalls/add_key02: remove test Eric Biggers
2017-06-05 17:48 ` [LTP] " Eric Biggers
2017-06-05 17:48 [PATCH 0/2] ltp: update add_key tests for nonempty NULL payload fix Eric Biggers
2017-06-05 17:48 ` [LTP] " Eric Biggers
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=20170606170425.GA88445@gmail.com \
--to=ebiggers3@gmail.com \
--cc=keyrings@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.