* Ingo Molnar <mi...@kernel.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
