[llvm-dev] retpoline mitigation and 6.0

[David Woodhouse via llvm-dev]

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.

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180208/b261459d/attachment.bin>