All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dmitry V. Levin" <ldv@altlinux.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	Network Development <netdev@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	linux-arch <linux-arch@vger.kernel.org>,
	Jiri Olsa <jolsa@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v2] bpf: fix uapi bpf_prog_info fields alignment
Date: Tue, 25 Jun 2019 18:36:29 +0300	[thread overview]
Message-ID: <20190625153629.GB24947@altlinux.org> (raw)
In-Reply-To: <CAADnVQJNLk7tAHRHr7V7ugvCX9iCjaH4_vS9YuNWcMpwnA6ZyA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]

On Tue, Jun 25, 2019 at 08:19:35AM -0700, Alexei Starovoitov wrote:
> On Tue, Jun 25, 2019 at 8:08 AM Dmitry V. Levin <ldv@altlinux.org> wrote:
> > On Tue, Jun 25, 2019 at 07:16:55AM -0700, Alexei Starovoitov wrote:
> > > On Tue, Jun 25, 2019 at 4:07 AM Baruch Siach <baruch@tkos.co.il> wrote:
> > > >
> > > > Merge commit 1c8c5a9d38f60 ("Merge
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next") undid the
> > > > fix from commit 36f9814a494 ("bpf: fix uapi hole for 32 bit compat
> > > > applications") by taking the gpl_compatible 1-bit field definition from
> > > > commit b85fab0e67b162 ("bpf: Add gpl_compatible flag to struct
> > > > bpf_prog_info") as is. That breaks architectures with 16-bit alignment
> > > > like m68k. Embed gpl_compatible into an anonymous union with 32-bit pad
> > > > member to restore alignment of following fields.
> > > >
> > > > Thanks to Dmitry V. Levin his analysis of this bug history.
> > > >
> > > > Cc: Jiri Olsa <jolsa@kernel.org>
> > > > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > > > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > > > ---
> > > > v2:
> > > > Use anonymous union with pad to make it less likely to break again in
> > > > the future.
> > > > ---
> > > >  include/uapi/linux/bpf.h       | 5 ++++-
> > > >  tools/include/uapi/linux/bpf.h | 5 ++++-
> > > >  2 files changed, 8 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > > index a8b823c30b43..766eae02d7ae 100644
> > > > --- a/include/uapi/linux/bpf.h
> > > > +++ b/include/uapi/linux/bpf.h
> > > > @@ -3142,7 +3142,10 @@ struct bpf_prog_info {
> > > >         __aligned_u64 map_ids;
> > > >         char name[BPF_OBJ_NAME_LEN];
> > > >         __u32 ifindex;
> > > > -       __u32 gpl_compatible:1;
> > > > +       union {
> > > > +               __u32 gpl_compatible:1;
> > > > +               __u32 pad;
> > > > +       };
> > >
> > > Nack for the reasons explained in the previous thread
> > > on the same subject.
> > > Why cannot you go with earlier suggestion of _u32 :31; ?
> >
> > By the way, why not use aligned types as suggested by Geert?
> > They are already used for other members of struct bpf_prog_info anyway.
> >
> > FWIW, we use aligned types for bpf in strace and that approach
> > proved to be more robust than manual padding.
> 
> because __aligned_u64 is used for pointers.

Does the fact that __aligned_u64 is used for pointers mean that
__aligned_u64 should not be used for anything but pointers?


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

      reply	other threads:[~2019-06-25 15:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-25 11:04 [PATCH v2] bpf: fix uapi bpf_prog_info fields alignment Baruch Siach
2019-06-25 14:16 ` Alexei Starovoitov
2019-06-25 15:08   ` Dmitry V. Levin
2019-06-25 15:19     ` Alexei Starovoitov
2019-06-25 15:36       ` Dmitry V. Levin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190625153629.GB24947@altlinux.org \
    --to=ldv@altlinux.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=arnd@arndb.de \
    --cc=ast@kernel.org \
    --cc=baruch@tkos.co.il \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=geert@linux-m68k.org \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=torvalds@linux-foundation.org \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.