Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption

Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption

[Steven Rostedt]

[ added stable folks ]

On Sun, 7 Jul 2019 11:17:09 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sun, Jul 7, 2019 at 8:11 AM Andy Lutomirski <luto@kernel.org> wrote:
> >
> > FWIW, I'm leaning toward suggesting that we apply the trivial tracing
> > fix and backport *that*.  Then, in -tip, we could revert it and apply
> > this patch instead.  
> 
> You don't have to have the same fix in stable as in -tip.
> 
> It's fine to send something to stable that says "Fixed differently by
> commit XYZ upstream". The main thing is to make sure that stable
> doesn't have fixes that then get lost upstream (which we used to have
> long long ago).
> 

But isn't it easier for them to just pull the quick fix in, if it is in
your tree? That is, it shouldn't be too hard to make the "quick fix"
that gets backported on your tree (and probably better testing), and
then add the proper fix on top of it. The stable folks will then just
use the commit sha to know what to take, and feel more confident about
taking it.

-- Steve

Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption

[Greg Kroah-Hartman]

On Wed, Jul 10, 2019 at 04:27:09PM -0400, Steven Rostedt wrote:
> 
> [ added stable folks ]
> 
> On Sun, 7 Jul 2019 11:17:09 -0700
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > On Sun, Jul 7, 2019 at 8:11 AM Andy Lutomirski <luto@kernel.org> wrote:
> > >
> > > FWIW, I'm leaning toward suggesting that we apply the trivial tracing
> > > fix and backport *that*.  Then, in -tip, we could revert it and apply
> > > this patch instead.  
> > 
> > You don't have to have the same fix in stable as in -tip.
> > 
> > It's fine to send something to stable that says "Fixed differently by
> > commit XYZ upstream". The main thing is to make sure that stable
> > doesn't have fixes that then get lost upstream (which we used to have
> > long long ago).
> > 
> 
> But isn't it easier for them to just pull the quick fix in, if it is in
> your tree? That is, it shouldn't be too hard to make the "quick fix"
> that gets backported on your tree (and probably better testing), and
> then add the proper fix on top of it. The stable folks will then just
> use the commit sha to know what to take, and feel more confident about
> taking it.

It all depends on what the "quick fix" is.  The reason I want to take
the exact same patch that is in Linus's tree is that 95% of the time
that we do a "one off" patch for stable only, it's wrong.  We _ALWAYS_
get it wrong somehow, it's crazy how bad we are at this.  I don't know
why this is, but we have the stats to prove it.

Because of this, I now require the "one off" stable only fixes to get a
bunch of people reviewing it and write up a bunch of explaination as to
why this is the way it is and why we can't just take whatever is in
mainline.

thanks,

greg k-h

Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption

[Sasha Levin]

On Wed, Jul 10, 2019 at 04:27:09PM -0400, Steven Rostedt wrote:
>
>[ added stable folks ]
>
>On Sun, 7 Jul 2019 11:17:09 -0700
>Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> On Sun, Jul 7, 2019 at 8:11 AM Andy Lutomirski <luto@kernel.org> wrote:
>> >
>> > FWIW, I'm leaning toward suggesting that we apply the trivial tracing
>> > fix and backport *that*.  Then, in -tip, we could revert it and apply
>> > this patch instead.
>>
>> You don't have to have the same fix in stable as in -tip.
>>
>> It's fine to send something to stable that says "Fixed differently by
>> commit XYZ upstream". The main thing is to make sure that stable
>> doesn't have fixes that then get lost upstream (which we used to have
>> long long ago).
>>
>
>But isn't it easier for them to just pull the quick fix in, if it is in
>your tree? That is, it shouldn't be too hard to make the "quick fix"
>that gets backported on your tree (and probably better testing), and
>then add the proper fix on top of it. The stable folks will then just
>use the commit sha to know what to take, and feel more confident about
>taking it.

I'd say that if the "final" fix is significantly different than what
we'll end up with upstream then just do as Linus said and send us a
separate backport.

If we try doing the apply fix/revert etc games it'll just be more
difficult later on to parse what has happened. On the other hand, if we
have a clear explanation in the backported commit as to how it's
different from upstream and the reasons for doing so it'll make future
us happy when we try to apply fixes on top of it.

--
Thanks,
Sasha

Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption

[Peter Zijlstra]

On Wed, Jul 10, 2019 at 04:27:09PM -0400, Steven Rostedt wrote:

> But isn't it easier for them to just pull the quick fix in, if it is in

Steve, I've not yet seen a quick fix that actually fixes all the
problems.

Your initial one only fixes the IRQ tracing one, but leaves the context
tracking one wide open.