Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20181128140852.178260-1-liuxiaozhou@bytedance.com> <CANiq72kzHqQ-M2Gyrf7iy1BQMabM6txChYwa8hrDkMmc3w8ORw@mail.gmail.com>
In-Reply-To: <CANiq72kzHqQ-M2Gyrf7iy1BQMabM6txChYwa8hrDkMmc3w8ORw@mail.gmail.com>
From:   Nick Desaulniers <ndesaulniers@google.com>
Date:   Tue, 4 Dec 2018 13:21:25 -0800
Message-ID: <CAKwvOdk3K_fUU-nUbpDVXvGr0CzBzznZOjCJN1cg2T+aW2vTEg@mail.gmail.com>
Subject: Re: [PATCH] Compiler Attributes: move kernel-only attributes into __KERNEL__
To:     Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc:     liuxiaozhou@bytedance.com,
        Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
        paul.burton@mips.com,
        Masahiro Yamada <yamada.masahiro@socionext.com>,
        Arnd Bergmann <arnd@arndb.de>,
        LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Greg KH <gregkh@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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 =E2=80=98__gnu_inline=E2=80=99"
> >
> > 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


--=20
Thanks,
~Nick Desaulniers