[llvm-dev] retpoline mitigation and 6.0

[Chandler Carruth via llvm-dev]

On Thu, Feb 8, 2018 at 3:59 PM David Woodhouse <dwmw2 at infradead.org> wrote:

> On Thu, 2018-02-08 at 23:48 +0000, Chandler Carruth wrote:
> > Bringing everything back to this thread -- we now have %V support
> > landed in top-of-tree, so wanted to get confirmation that top-of-tree
> > is healthy for the kernel, or see what else we need to do.
>
> For 64-bit it's fine. For 32-bit we *think* the retpoline bits are OK
> but it doesn't build for other reasons on 32-bit. But that isn't new
> breakage — 5.0 has the same problem with the latest kernel. I'll see if
> we can work around that in the kernel, instead of relying on certain
> inline asms getting optimised away before the compiler ever notices
> that they're bogus.
>

Cool, let us know if we can help here, but this at least tells us that
we're in pretty good shape to start backporting everything.


>
> > David, you had offered to work on the attribute: I'm actually happy
> > to do that if you want to focus on testing things.
>
> That sounds good to me; thanks.
>
> >  One question I have: how important is this? Specifically, does the
> > attribute need to get backported?
>
> No, we can live without it. It's a slight performance optimisation,
> that none of the init code in the kernel itself actually has to be
> built with retpolines. But it isn't imperative.
>

Makes sense, I'll do this as part of the requested cleanup to how we model
whether or not to do retpolines.

Thanks,
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180209/a2984646/attachment.html>