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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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