linux-kernel - Re: [PATCH v2 2/2] Compiler Attributes: naked can be shared

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 20 Sep 2018 09:36:50 +0200
From:   Dominique Martinet <asmadeus@...ewreck.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Eli Friedman <efriedma@...eaurora.org>,
        Christopher Li <sparse@...isli.org>,
        Kees Cook <keescook@...omium.org>,
        Ingo Molnar <mingo@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Joe Perches <joe@...ches.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-sparse@...r.kernel.org
Subject: Re: [PATCH v2 2/2] Compiler Attributes: naked can be shared

Greg Kroah-Hartman wrote on Thu, Sep 20, 2018:
> "Fixes:" is not just for stable, we use it wherever we have a patch that
> we know fixes a problem introduced in another patch.
> 
> For this instance, I think we should just revert the offending patch,
> which should resolve the issue for everyone and then you can try to redo
> your series to get it right the next time.
> 
> Sound good?

Except that 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h
mutually exclusive") itself fixes cafa0010cd51 ("Raise the minimum
required gcc version to 4.6"), which breaks clang altogether (as used by
example by bcc for most BPF programs, that I caught before -rc1 got
released so we got both in rc1)

I'm not aware of anything that would break if both were to be reverted,
I have no opinion on which way to go.

> Why not just route these through Andrew?  He takes lots of stuff like
> this for this very reason.

That works for me (although it might have helped if Andrew had been in
Cc at any point in this discussion...), but part of the discussion was
about seriously maintaining these files, and Miguel stepped up to help
with that so it could make sense to have his own tree.

Frankly, after this whole episode I'd find quite helpful if "compiler
stuff" (or headers maintainance in general) were to grow its own mailing
list and start being considered like a proper component of the kernel.

It does impact quite a few people, and it's neigh-impossible to review
this stuff as things are right now with a hand-picked list of CCs, no
matter how large it is -- I don't mind if it goes in -next through its
own branch or through Andrew, but a proper place where folks interested
in these could subscribe and test/review the patches would be awesome.

-- 
Dominique Martinet