From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>,
Kees Cook <keescook@chromium.org>, Shuah Khan <shuah@kernel.org>,
Sumit Semwal <sumit.semwal@linaro.org>,
Brian Norris <computersforpeace@gmail.com>,
Jiri Kosina <jkosina@suse.cz>,
LKML <linux-kernel@vger.kernel.org>,
"# 3.4.x" <stable@vger.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
Shuah Khan <shuahkh@osg.samsung.com>
Subject: Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]
Date: Sat, 24 Jun 2017 06:45:37 +0200 [thread overview]
Message-ID: <20170624044537.GD10973@kroah.com> (raw)
In-Reply-To: <20170624003407.GZ21846@wotan.suse.de>
On Sat, Jun 24, 2017 at 02:34:07AM +0200, Luis R. Rodriguez wrote:
> So taking the position that any kselftest script on linux-next or a future
> kernel should never break stable implicate that *any* fix going upstream for
> which there is a respective ksefltest test *must* have a stable upstream fix.
What, no! If it's a bug, that kselftest points out, great, it's up to
stable or a vendor to backport that fix if they want it.
Again, it's just like any other test suite, look at xfstests, no one
gets mad when it adds new tests that fail on old kernels, due to bugs
there, right?
> Its not obvious to me that everyone is aware of this. What do we do about
> those cases where we *don't* want a stable fix due to the complexity?
That's up to the stable maintainers or the vendors that maintain their
own kernel trees.
thanks,
greg k-h
next prev parent reply other threads:[~2017-06-24 4:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-22 16:18 seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures] Sumit Semwal
2017-06-22 16:53 ` Kees Cook
2017-06-22 17:09 ` Shuah Khan
2017-06-22 17:49 ` Andy Lutomirski
2017-06-22 17:50 ` Kees Cook
2017-06-22 19:06 ` Shuah Khan
2017-06-22 19:48 ` Tom Gall
2017-06-22 20:23 ` Shuah Khan
2017-06-23 4:02 ` Sumit Semwal
2017-06-23 15:36 ` Shuah Khan
2017-06-23 19:03 ` Shuah Khan
2017-06-23 19:44 ` Tom Gall
2017-06-23 1:52 ` Greg Kroah-Hartman
2017-06-23 2:40 ` Andy Lutomirski
2017-06-23 4:05 ` Kees Cook
2017-06-24 0:34 ` Luis R. Rodriguez
2017-06-24 4:45 ` Greg Kroah-Hartman [this message]
2017-06-26 21:44 ` Luis R. Rodriguez
2017-06-24 4:43 ` Greg Kroah-Hartman
2017-07-05 14:59 ` Sumit Semwal
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=20170624044537.GD10973@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=computersforpeace@gmail.com \
--cc=jkosina@suse.cz \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mcgrof@kernel.org \
--cc=shuah@kernel.org \
--cc=shuahkh@osg.samsung.com \
--cc=stable@vger.kernel.org \
--cc=sumit.semwal@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).