[llvm-dev] retpoline mitigation and 6.0
Chandler Carruth via llvm-dev
llvm-dev at lists.llvm.org
Thu Feb 8 16:09:11 PST 2018
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev