netdev - Re: [PATCH] Compiler Attributes: move kernel-only attributes into __KERNEL_

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]

Message-ID: <CANiq72=uwbHqPB_1b7q+dD7FaqZ+HOmOvXMPX3d=z7-xqzwFzQ@mail.gmail.com>
Date:   Thu, 29 Nov 2018 11:42:11 +0100
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     lxz1983@...il.com
Cc:     Network Development <netdev@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>, ast@...nel.org,
        daniel@...earbox.net, yhs@...com, jakub.kicinski@...ronome.com,
        quentin.monnet@...ronome.com
Subject: Re: [PATCH] Compiler Attributes: move kernel-only attributes into __KERNEL__

On Thu, Nov 29, 2018 at 3:16 AM Xiaozhou Liu <lxz1983@...il.com> wrote:
>
> On Wed, Nov 28, 2018 at 06:35:18PM +0100, Miguel Ojeda wrote:
>
> By `these' I mean inline and the like, to be clear.

Ah, that makes more sense! Sorry.

> > That is not exactly correct -- a3f8a30f3f00 moved some attributes to
> > another file, moving them into __KERNEL__ (in particular,__gnu_inline
> > is).
>
> Yes, that is what a3f8a30f3f00 did. Sorry.
> Turns out the commits in question are 815f0ddb346c and a3f8a30f3f00.

No problem! It was a bit confusing indeed.

> Yes and no. Let's recall the whole story.
>
> Before 815f0ddb346c("include/linux/compiler*.h: make compiler-*.h mutually exclusive"),
> __gnu_inline and inline were both *in* __KERNEL__ as the were in
> <linux/compiler-gcc.h>, which was entirely put to __KERNEL__ in
> <linux/compiler_types.h>. Everything was fine.
>
> Then 815f0ddb346c moved inline and __gnu_inline *out* of __KERNEL__
> and put them in <linux/compiler_types.h> so userspace could see them
> both. Not sure if it's intended behavior, but everything looked fine.
>
> Then a3f8a30f3f00 moved __gnu_inline back into __KERNEL__ and left
> inline behind. Since inline depends on __gnu_inline, error showing
> "unknown type name ‘__gnu_inline’" pops up.

Exactly, thanks a lot for clarifying it up (we should put this in the
commit message, I would say). That also answers my question: it is
clear everything should be back into __KERNEL__. The only worry is
that the v4.19 release contained 815f0ddb346c, so it has them exposed,
so someone could have started relying on them. Or, more likely, the
exposed macros could break some source code out there. Hm... Should a
"fix" be backported?

Cheers,
Miguel