[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170626214415.GG21846@wotan.suse.de>
Date: Mon, 26 Jun 2017 23:44:15 +0200
From: "Luis R. Rodriguez" <mcgrof@...nel.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: "Luis R. Rodriguez" <mcgrof@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
Kees Cook <keescook@...omium.org>,
Shuah Khan <shuah@...nel.org>,
Sumit Semwal <sumit.semwal@...aro.org>,
Brian Norris <computersforpeace@...il.com>,
Jiri Kosina <jkosina@...e.cz>,
LKML <linux-kernel@...r.kernel.org>,
"# 3.4.x" <stable@...r.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>,
Shuah Khan <shuahkh@....samsung.com>
Subject: Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS
testing with latest kselftests - some failures]
On Sat, Jun 24, 2017 at 06:45:37AM +0200, Greg Kroah-Hartman wrote:
> 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.
Makes sense!
> 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?
Correct but that means there is an information gap of which test cases fit into
this category. An option to run kselftest with the ability to only run tests
designed to also include stable would be good, otherwise Sumit Semwal or others
would be sending reports or issues for things folks already designed the fix to
*not* be a stable candidate. This actually would also prove useful to
distributions to ensure to then run kselftest as part of their distribution
test suite with all bells and whistles enabled so that they can make a
determination of what questionable "fixes" things to fold in somehow.
Unless of course we want these discussions to purposely bubble up as an
alternative to this kselftest option. It seems rather wasteful though.
> > 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.
But if the above is already decided having folks send emails about it
seems pointless.
Luis
Powered by blists - more mailing lists