[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180215081646.px477klttsj6axgp@gmail.com>
Date: Thu, 15 Feb 2018 09:16:46 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andy Lutomirski <luto@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Dan Williams <dan.j.williams@...el.com>,
Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: [GIT PULL] x86 PTI and Spectre related fixes and updates
* Ingo Molnar <mingo@...nel.org> wrote:
> > > This is not a complaint so much as a "is it worth it?" question..
> >
> > So far, I think this is the first conflict it's generated in a long
> > time, so previously it was worth it from my point of view. As long as
> > it doesn't cause more work for the TIP maintainers, or for you, I
> > appreciate it. But if it does cause more work, don't worry about it, I
> > can handle backporting things as needed.
>
> Note that the role of x86/pti is not just to identify backporting commits for
> -stable, but to allow us on the x86 tree side to see how current upstream work
> interacts, and proactively allow us to group commits in a low-friction fashion.
>
> So even if you didn't follow the x86/pti branch at all, -stable would _still_
> benefit from the tip:x86/pti approach and the inherent backportability of all the
> PTI and Spectre commits.
Put differently: this approach isn't a zero-sum game of 'upstream conflicts versus
-stable conflicts', where if we don't resolve a conflict upstream then -stable has
to do it and vice versa.
The tip:x86/pti approach actively avoided literally _dozens_ of nasty conflicts in
the -stable space, at an (IMHO) much lower cost to upstream. It also IMHO
successfully avoided the destabilizing effect that otherwise the backporting of
most of ~300 these commits would have caused on the widely deployed v4.14 and
v4.15 base kernels ....
Had I done this latest pull request a bit smarter Linus would not have seen these
two conflicts either, so I still think this is the right approach and the cost to
upstream is very low.
The x86 tree maintenance overhead was obviously higher due to all this, but right
now I'm reasonably happy about the backporting aspect/overhead, because the v4.14
and v4.15 stable kernels are now essentially using and testing our latest upstream
code, which allows it to stabilize a lot faster.
Thanks,
Ingo
Powered by blists - more mailing lists