From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.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>,
"Luis R. Rodriguez" <mcgrof@kernel.org>,
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 02:34:07 +0200 [thread overview]
Message-ID: <20170624003407.GZ21846@wotan.suse.de> (raw)
In-Reply-To: <CALCETrVHufkOBs0oZ7TUaxr48SNkSn-cWBB26cArQtEcq3431A@mail.gmail.com>
On Thu, Jun 22, 2017 at 07:40:49PM -0700, Andy Lutomirski wrote:
> On Thu, Jun 22, 2017 at 6:52 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Thu, Jun 22, 2017 at 10:50:43AM -0700, Kees Cook wrote:
> >> On Thu, Jun 22, 2017 at 10:49 AM, Andy Lutomirski <luto@kernel.org> wrote:
> >> > On Thu, Jun 22, 2017 at 10:09 AM, Shuah Khan <shuah@kernel.org> wrote:
> >> >> On 06/22/2017 10:53 AM, Kees Cook wrote:
> >> Right. I really think stable kernels should be tested with their own
> >> selftests. If some test is needed in a stable kernel it should be
> >> backported to that stable kernel.
> >
> > Well, ideally all new features added to the kernel should be able to be
> > detected by userspace somehow if they are present or not.
> >
> > How do you expect a program to know if a feature has "failed" or is just
> > "not enabled/present in this kernel"? Normally with syscalls this is
> > easy, same for sysfs changes. Is seccomp in the bad state where there
> > is no way to detect the two different states here? How is userspace
> > supposed to deal with that?
> >
> > We make fun of glibc having a zillion crazy tests to determine kernel
> > features, and recently, just not wrapping new syscalls at all because
> > they are just frustrated at the compatibility issues over time. Let's
> > not make their life any harder than it has to be please.
> >
> > I don't see how any of the kselftest programs are any different than any
> > other userspace program that wants to use our kernel api, and as such,
> > any version of kselftest should be able to successfully run on any
> > kernel release. If not, then we messed up in how we either wrote the
> > test, or how we added a new kernel api. Neither is acceptable.
>
> That's a fair point.
I agreed with it as well just a few threads ago due to similar issues, however,
thinking this over I'm afraid this has some interesting side consequences for
fixes and what code goes upstream into kselftest.
<-- snip -->
> The problem is that the fix is moderately intrusive and doesn't seem
> like a great candidate for backporting, although we could plausibly do
> it.
Such is the case often actually.
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.
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?
Luis
next prev parent reply other threads:[~2017-06-24 0:34 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 [this message]
2017-06-24 4:45 ` Greg Kroah-Hartman
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=20170624003407.GZ21846@wotan.suse.de \
--to=mcgrof@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=gregkh@linuxfoundation.org \
--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=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).