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

[Nick Desaulniers <ndesaulniers@google.com>]

On Wed, Nov 28, 2018 at 9:35 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> Hi Xiaozhou,
>
> On Wed, Nov 28, 2018 at 3:09 PM Xiaozhou Liu <liuxiaozhou@bytedance.com> wrote:
> >
> > Attributes such as `__gnu_inline' are meant to be used within the
> > kernel. When userspace somehow includes <linux/compiler.h>
> > (eg. tools/bpf), compilation errors would be shown:
> >
> >         "error: unknown type name ‘__gnu_inline’"
> >
> > So just move these things into __KERNEL__ and the behavior is kept
> > as before.
>
> That is not exactly correct -- a3f8a30f3f00 moved some attributes to
> another file, moving them into __KERNEL__ (in particular,__gnu_inline
> is).
>
> The problem is, instead, that __gnu_inline is not anymore defined
> outside __KERNEL__, but something else that uses it is (the inline
> macro definition, if I had to guess).
>
> If your problem is fixed by putting __gnu_inline into __KERNEL__
> again, it means we can simply move the inline definition inside
> __KERNEL__ too. That way, we don't pollute userspace users with macro
> definitions.
>
> Having said that, does someone know whether userspace should have
> access to those attributes (or rather, other code that uses in turn
> those attributes)?

This is tricky territory; the kernel is redefining `inline` in headers
in order to get __attribute__((gnu_inline)) semantics.  If non kernel
users include those headers, the kernel may be redefining the
semantics of `inline` for those programs (unexpectedly).  Admittedly,
gnu_inline kind of an edge case so most users might not notice, but
that may be an argument for `-f gnu_inline` rather than redefining
`inline` in a header.

>
> Cheers,
> Miguel



-- 
Thanks,
~Nick Desaulniers