Re: [tip:x86/urgent] x86/mm/kaslr: Use the _ASM_MUL macro for multiplication to work around Clang incompatibility

[Matthias Kaehlcke]

El Fri, May 05, 2017 at 12:30:20PM -0700 Linus Torvalds ha dit:

> On Fri, May 5, 2017 at 11:44 AM, Matthias Kaehlcke <mka@xxxxxxxxxxxx> wrote:
> >
> > Indeed, I expect 4.12 (with this patch ...) to build with Clang for a
> > x86 defconfig (with tons of warnings). ARM64 is very close.
> 
> Does it actually *work*, rather than just build?

Unfortunately I can't make an universal affirmation here. The systems
for which I currently develop run a 4.4ish kernel with the clang
patches on top. Both x86 and ARM64 boot, the peripherals work and I
haven't encountered any specific problems yet. Automated tests to
assess or detect regressions are still pending.

Does it work on all possible hardware configurations and use cases?
Almost certainly not. However I think here is where having basic
upstream support for clang can help by allowing more people to
evaluate it on their systems without requiring a whole bunch of random
out-of-tree patches, which also makes it easier to contribute back.

> clang used to have actual code generation bugs that made for really
> subtle kernel issues but didn't matter very often in user space.
> 
> The thing that comes to mind is the crazy handling of spilling
> 'eflags' on x86 (saving and restoring eflags over a function call in
> order to save the arithmetic flags, but in the process also undoing
> the changes to IF that that function call did.
> 
> That was a horrible horrible bug - it generates slow code, but it was
> actually *incorrect* code too. It's just that in user space, people
> very seldom mess with the non-arithmetic flags (things like IOPL, IF,
> AC, etc - they *can* be used in user space but seldom are).
> 
> Some of the discussion I saw by the clang people pooh-poohed that bug
> and seemed to think it was a kernel problem.
> 
> That kind of pure incompetence from compiler people doesn't make me
> get the warm and fuzzies.
> 
> Generating code that is actively _wrong_ and performs badly too - hey
> that happens. But then making excuses for clearly buggy code
> generation?
> 
> I did have a report saying it was fixed, so hopefully saner people prevailed.
> 
> But it left a really bad taste, and it was an example of something
> that may have built fine, but generated subtle broken code (where
> "subtly" here means "it might work when you don't look too closely and
> are lucky, and then cause lockups in odd situations").
> 
> I'd love to be able to compile the kernel with clang, but only if the
> clang people take it seriously.

I only started looking into clang a few months ago, and can't really
comment on the cases you mention. My expectation is that performance
and stability issues will be taken quite seriously when clang kernel
builds are more widely used on business critical production systems.

Cheers

Matthias