lkml.org 
[lkml]   [2018]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] x86 PTI and Spectre related fixes and updates

* Greg Kroah-Hartman <gregkh@linuxfoundation.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@kernel.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

\
 
 \ /
  Last update: 2018-02-15 09:04    [W:0.245 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site