Message-ID: <20180215080324.3reffabx76w7ujyy@gmail.com>
Date:   Thu, 15 Feb 2018 09:03:24 +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


* Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:

> On Wed, Feb 14, 2018 at 05:17:25PM -0800, Linus Torvalds wrote:
> > On Wed, Feb 14, 2018 at 4:38 PM, Ingo Molnar <mingo@...nel.org> wrote:
> > >
> > >    This tree generates two relatively simple conflicts with your tree:
> > 
> > So what annoys me about these conflicts is that I'm not convinced that
> > the stable tree actually *uses* your fancy x86/pti branch?
> > 
> > I think stable ends up working like a patch-queue anyway due to how
> > Greg works and all his helper scripts, so the whole "let's keep a
> > branch for pti" ends up being of dubious advantage when it results in
> > conflicts on merging, and it's not the same commits in the end anyway.
> 
> I do use it, I take the commits from there and then queue them up as
> individual patches for the stable releases.

Also note that these two conflicts came in recently - and today I eliminated them 
by switching x86/pti over to a clean v4.16 base (d4667ca14261). I'd have done this 
v4.16 backmerge earlier, had I realised that it's a problem to Linus!

Also:

> And if it wasn't there, the conflict resolution would have to be on my
> side, making them "not the same commits in the end", so either I have to
> do that, or you do :)

If tip:x86/pti wasn't there, I do claim that your -stable conflict resolution and 
stabilization work would have been a _LOT_ harder:

> > 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.

There is no way we could have done this via the classic -stable tagging approach 
alone: the sheer scale of this effort (over 300 backported non-driver commits to 
core code) is almost two magnitudes higher than the Cc: stable commit tagging 
approach is usually applied to!

Also note that while x86/pti was v4.15 based yesterday and is pure v4.16+ based 
today, it's still fundamentally two (mostly) linear sets of commits:

   # v4.14 base
   v4.14..e5d77a73f364          # 71 commits: The original 'cherry-picked/merged' PTI base

   e5d77a73f364..64e16720ea08   # 167 linear commits: PTI and Spectre v4.15 work

   7e86548e2cc8                 # merge v4.15-final into x86/pti

   7e86548e2cc8..e48657573481   # 78 linear commits + 1 limited KVM merge of related changes

   d4667ca14261                 # today I switched x86/pti to this v4.16-rc1 
                                # upstream commit that includes all of x86/pti

   d4667ca14261..x86/pti        # third backporting range starts today, empty now

The "backporting value-add" here is that this short description compactly and 
unambiguously identifies a set of _316_ commits to very fragile pieces of low 
level x86 code (75% of which are must-have 'fixes' in the PTI/Spectre sense) that 
need to be applied to get v4.14 to the latest PTI and Spectre code,

Had we done this the usual way I do claim that it would have generated about a 
dozen nasty conflicts in v4.14 already by today, due to the sheer number and scope 
of PTI and Spectre commits, and the fragility and complexity of the underlying x86 
code.

Note that via the x86/pti approach the relevant v4.14.y x86 arch code is still 
almost 100% shared with Linus's latest tree, where testing results flow both 
downstream and upstream, even though it's cherry-picked and technically not the 
same tree in the Git space.

We'll see how this evolves in the v4.17 development window: PTI has already calmed 
down and things are calming down now for Spectre as well, so maybe we can switch 
back to the -stable tagging method and rely on -stable side conflict resolution.

OTOH exactly because things are calming down we can still keep x86/pti and 
robustly group, test and document the list of commits to backport. But we won't 
overdo it.

Thanks,

	Ingo

Powered by blists - more mailing lists