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]
Message-ID: <20180822043230.GA26654@nautica>
Date:   Wed, 22 Aug 2018 06:32:30 +0200
From:   Dominique Martinet <asmadeus@...ewreck.org>
To:     Joe Perches <joe@...ches.com>
Cc:     Nick Desaulniers <ndesaulniers@...gle.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Kees Cook <keescook@...omium.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>,
        Arnd Bergmann <arnd@...db.de>, dwmw@...zon.co.uk,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Will Deacon <will.deacon@....com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] compiler-gcc: get back Clang build

Joe Perches wrote on Tue, Aug 21, 2018:
> On Wed, 2018-08-22 at 06:16 +0200, Dominique Martinet wrote:
> > I think that could work, but at the point making a separate
> > compiler-common.h and not including compiler-gcc.h for clang sounds
> > better to me... More importantly here, either solution sound complex
> > enough to require more than a few days and proper testing for all archs
> > etc when compared to the partial revert we have here.
> 
> The immediate need for a partial revert seems unnecessary as
> clang hasn't really worked for a couple releases now.

Sorry for repeating myself, clang is used by bcc for compiling BPF
programs (e.g. bpf_module_create_c_from_string() or any similar function
will use the clang libs to compile the bpf program with linux headers),
and this has always been working because it's not using our makefiles.

This broke today in master and I only joined this thread after looking
at why the build started failing today and noticing this patch, it
definitely hasn't been broken for two releases, or I wouldn't be here
with this timing :)


> The separate compiler file changes are much more sensible,
> even if it takes a few days.

A few days are fine, but I think some form of fix in 4.19-rc1 would be
good.

I'll stop taking your time now, but I think you are/were underestimating
how many people use clang with the linux kernel headers indirectly.
BPF is a well-used tool :)


Thanks,
-- 
Dominique Martinet

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ