lkml.org 
[lkml]   [2018]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4.16 234/279] x86/pkeys/selftests: Adjust the self-test to fresh distros that export the pkeys ABI
On Sun, Jul 08, 2018 at 08:33:37PM +1000, Michael Ellerman wrote:
> Ingo Molnar <mingo@kernel.org> writes:
> > * Michael Ellerman <mpe@ellerman.id.au> wrote:
> >> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> >> > On Tue, Jul 03, 2018 at 01:36:43PM +0200, Vlastimil Babka wrote:
> >> >> On 06/18/2018 10:13 AM, Greg Kroah-Hartman wrote:
> >> >> > 4.16-stable review patch. If anyone has any objections, please let me know.
> >> >>
> >> >> So I was wondering, why backport such a considerable number of
> >> >> *selftests* to stable, given the stable policy? Surely selftests don't
> >> >> affect the kernel itself breaking for users?
> >> >
> >> > These came in as part of Sasha's "backport fixes" tool. It can't hurt
> >> > to add selftest fixes/updates to stable kernels, as for some people,
> >> > they only run the selftests for the specific kernel they are building.
> >> > While others run selftests for the latest kernel on older kernels, both
> >> > of which are valid ways of testing.
> >>
> >> I don't have a problem with these sort of patches being backported, but
> >> it seems like Documentation/process/stable-kernel-rules.txt could use an
> >> update?
> >>
> >> I honestly don't know what the rules are anymore.
> >
> > Self-tests are standalone tooling which help the testing of the kernel, and it
> > makes sense to either update all of them, or none of them.
>
> Yes I know what selftests are.
>
> > Here it makes sense to update all of them, because if a self-test on a stable
> > kernel shows a failure then a fix is probably missing from -stable, right?
>
> Usually, though it's not always that simple IME.
>
> But sure, I don't have a problem with updating selftests, I said that before.
>
> > Also note that self-test tooling *cannot possibly break the kernel*, because they
> > are not used in the kernel build process, so the normally conservative backporting
> > rules do not apply.
>
> Right. So stable-kernel-rules.txt could use an update to mention that.
>
>
> My comment was less about this actual patch and more about the new
> reality of patches being backported to stable based on Sasha's tooling,
> which seems to be much more liberal than anything we've done previously.
>
> I don't generally have any objection to that process, though it possibly
> could have been more widely announced. But, it would be good if
> stable-kernel-rules.txt was updated to mention it.
>
> I've had several people ask me "hey my patch got backported to stable
> but I didn't ask for it - is that OK, what's going on?" etc.

Why didn't those people just ask us? To not do so is very strange, it's
not like we are hard to find :)

> I guess I should just send a patch to update it, but I don't really know
> what it should say.

I don't think it really needs any changes, as the selftests is just a
corner case that is easily explained if anyone cares enough to actually
ask :)

thanks,

greg k-h

\
 
 \ /
  Last update: 2018-07-08 15:27    [W:0.083 / U:18.900 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site