linux-kernel - Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 17 Mar 2017 19:47:33 +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
Subject: Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array

On Fri, Mar 17, 2017 at 7:03 PM, Borislav Petkov <bp@...en8.de> wrote:
> On Fri, Mar 17, 2017 at 01:32:00PM +0100, Alexander Potapenko wrote:
>> > IIUC there's only a handful of VLAIS instances in LLVM code, why not
>> Sorry, "kernel code", not "LLVM code".
>> > just drop them for the sake of better code portability?
>
> And what happens if someone else adds a variable thing like this
> somewhere else, builds with gcc, everything's fine and patch gets
> applied? Or something else llvm can't stomach.
>
> Does that mean there'll be the occasional, every-so-often whack-a-mole
> patchset from someone, fixing the kernel build with llvm yet again?


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). 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.