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

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Matthias Kaehlcke <mka@chromium.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Michael Davidson <md@google.com>,
	Thomas Gleixner <tglx@linutronix.de>, Peter Anvin <hpa@zytor.com>,
	grundler@chromium.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ghackmann@google.com, Kees Cook <keescook@chromium.org>,
	"linux-tip-commits@vger.kernel.org" 
	<linux-tip-commits@vger.kernel.org>
Subject: Re: [tip:x86/urgent] x86/mm/kaslr: Use the _ASM_MUL macro for multiplication to work around Clang incompatibility
Date: Fri, 5 May 2017 12:30:20 -0700	[thread overview]
Message-ID: <CA+55aFzujof+LjiL_ErR3Js1qdH0X8E3GKMC5HfkOYQYs3PGBA@mail.gmail.com> (raw)
In-Reply-To: <20170505184405.GB128305@google.com>

On Fri, May 5, 2017 at 11:44 AM, Matthias Kaehlcke <mka@chromium.org> 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?

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.

            Linus