Re: Spectre-v2 (IBPB/IBRS) and SSBD fixes for 4.4.y

[Greg KH <gregkh@linuxfoundation.org>]

On Sat, Jul 14, 2018 at 07:27:55AM +0200, Willy Tarreau wrote:
> Hi Srivatsa,
> 
> just a small personal comment below since I'm not the 4.4 maintainer :-)
> 
> On Fri, Jul 13, 2018 at 02:49:14PM -0700, Srivatsa S. Bhat wrote:
> > You'll notice that the initial few patches in this series include
> > cleanups etc., that are non-critical to IBPB/IBRS/SSBD. Most of these
> > patches are aimed at getting the cpufeature.h vs cpufeatures.h split
> > into 4.4, since a lot of the subsequent patches update these headers.
> > On my first attempt to backport these patches to 4.4.y, I had actually
> > tried to do all the updates on the cpufeature.h file itself, but it
> > started getting very cumbersome, so I resorted to backporting the
> > cpufeature.h vs cpufeatures.h split and their dependencies as well.
> 
> When I used to maintain 2.6.32, initially I tried to backport the minimal
> amount of changes. It quickly resulted in certain files (mostly includes)
> diverging a lot from more recent versions, making it a real pain to later
> backport other fixes. Worse, sometimes I would even not be 100% confident
> in my backports (eg: macros being declared very differently or at multiple
> places which I could easily miss). For 3.10, I stopped doing that and
> instead preferred to pick a bit more "noise" to prepare and adapt the
> files to be patched so that overall the code looked more similar to more
> recent versions. I found that not only it helped with backports, but it
> also reduced the amount of breakage introduced for later backports, and
> it helped with reviews, since what matters is not that the old kernel
> is correct but that the recent one is, and if the code is the same then
> the old one is correct.
> 
> Thus based on my experiences with two different methods I guess that I
> had the best approach here.

Yes, taking the "noise" has been found to be better over time.  But, for
these patches, I haven't taken that change to 4.9 just yet, and it is
causing a headache for people.  Perhaps we should do it there too?  I
don't want 4.9 to be the odd-ball kernel where we didn't do it, that
will just cause more problems over time.

> > I would appreciate if you could kindly consider these patches for
> > review and inclusion in a future 4.4.y release.
> 
> However here I notice that your patches were not CCed to their respective
> authors nor to the list of participants, I predict that Greg will ask you
> for this as they're almost the only ones understanding their own tricks ;-)

Ah, you beat me to it :)

Yes, you should resend and cc: all of the authors and reviewers, I want
their feedback if at all possible.

Normally it's hard to not do that using git send-email, so you had to do
extra work to prevent this from happening...

thanks,

greg k-h