From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752863AbdEEUwx (ORCPT ); Fri, 5 May 2017 16:52:53 -0400 Received: from mail-pg0-f47.google.com ([74.125.83.47]:36745 "EHLO mail-pg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751266AbdEEUwv (ORCPT ); Fri, 5 May 2017 16:52:51 -0400 Date: Fri, 5 May 2017 13:52:49 -0700 From: Matthias Kaehlcke To: Linus Torvalds Cc: Ingo Molnar , Peter Zijlstra , Michael Davidson , Thomas Gleixner , Peter Anvin , grundler@chromium.org, Linux Kernel Mailing List , ghackmann@google.com, Kees Cook , "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 Message-ID: <20170505205249.GC128305@google.com> References: <20170501224741.133938-1-mka@chromium.org> <20170505102555.ysjep3foplmhspux@hirez.programming.kicks-ass.net> <20170505175039.hf3jx4ljuyzzgxdn@gmail.com> <20170505184405.GB128305@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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