[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+bybdpqB71=inx8amwr188Mb2QyBeRTDdWZ3AFyDwVX0A@mail.gmail.com>
Date: Fri, 17 Mar 2017 20:05:16 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Alexander Potapenko <glider@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Michael Davidson <md@...gle.com>,
Michal Marek <mmarek@...e.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
Shaohua Li <shli@...nel.org>,
Matthias Kaehlcke <mka@...omium.org>,
"x86@...nel.org" <x86@...nel.org>,
"open list:KERNEL BUILD + fi..." <linux-kbuild@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-crypto@...r.kernel.org, linux-raid@...r.kernel.org,
kbuild-all@...org, Fengguang Wu <fengguang.wu@...el.com>
Subject: Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array
On Fri, Mar 17, 2017 at 7:57 PM, Borislav Petkov <bp@...en8.de> wrote:
> On Fri, Mar 17, 2017 at 07:47:33PM +0100, Dmitry Vyukov wrote:
>> This problem is more general and is not specific to clang. It equally
>> applies to different versions of gcc, different arches and different
>> configs (namely, anything else than what a developer used for
>> testing).
>
> I guess. We do carry a bunch of gcc workarounds along with the cc-*
> macros in scripts/Kbuild.include.
>
>> A known, reasonably well working solution to this problem is
>> a system of try bots that test patches before commit with different
>> compilers/configs/archs. We already have such system in the form of
>> 0-day bots. It would be useful to extend it with clang as soon as
>> kernel builds.
>
> Has someone actually already talked to Fengguang about it?
+Fengguang
> Oh, and the stupid question: why the effort to build the kernel
> with clang at all? Just because or are there some actual, palpable
> advantages?
On our side it is:
- clang make it possible to implement KMSAN (dynamic detection of
uses of uninit memory)
- better code coverage for fuzzing
- why simpler and faster development (e.g. we can port our user-space
hardening technologies -- CFI and SafeStack)
You can also find some reasons in the Why section of LLVM-Linux project:
http://llvm.linuxfoundation.org/index.php/Main_Page
Powered by blists - more mailing lists