linux-kernel - Re: [RFC v3 2/5] bpf: Explicitly align bpf_res_spin

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <fdda632e-bac9-e830-8840-2fcd6b2292b6@linux-m68k.org>
Date: Thu, 9 Oct 2025 13:56:19 +1100 (AEDT)
From: Finn Thain <fthain@...ux-m68k.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
cc: Peter Zijlstra <peterz@...radead.org>, Will Deacon <will@...nel.org>, 
    Alexei Starovoitov <ast@...nel.org>, 
    Daniel Borkmann <daniel@...earbox.net>, 
    Andrii Nakryiko <andrii@...nel.org>, 
    Andrew Morton <akpm@...ux-foundation.org>, 
    Boqun Feng <boqun.feng@...il.com>, Jonathan Corbet <corbet@....net>, 
    Mark Rutland <mark.rutland@....com>, Arnd Bergmann <arnd@...db.de>, 
    LKML <linux-kernel@...r.kernel.org>, 
    linux-arch <linux-arch@...r.kernel.org>, 
    Geert Uytterhoeven <geert@...ux-m68k.org>, linux-m68k@...r.kernel.org, 
    Martin KaFai Lau <martin.lau@...ux.dev>, 
    Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
    Yonghong Song <yonghong.song@...ux.dev>, 
    John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, 
    Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, 
    Jiri Olsa <jolsa@...nel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [RFC v3 2/5] bpf: Explicitly align bpf_res_spin_lock


On Wed, 8 Oct 2025, Alexei Starovoitov wrote:

> On Tue, Oct 7, 2025 at 4:50 PM Finn Thain <fthain@...ux-m68k.org> wrote:
> >
> > Align bpf_res_spin_lock to avoid a BUILD_BUG_ON() when the alignment
> > changes, as it will do on m68k when, in a subsequent patch, the minimum
> > alignment of the atomic_t member of struct rqspinlock gets increased.
> > Drop the BUILD_BUG_ON() as it is now redundant.
> >
> > Cc: Martin KaFai Lau <martin.lau@...ux.dev>
> > Cc: Eduard Zingerman <eddyz87@...il.com>
> > Cc: Song Liu <song@...nel.org>
> > Cc: Yonghong Song <yonghong.song@...ux.dev>
> > Cc: John Fastabend <john.fastabend@...il.com>
> > Cc: KP Singh <kpsingh@...nel.org>
> > Cc: Stanislav Fomichev <sdf@...ichev.me>
> > Cc: Hao Luo <haoluo@...gle.com>
> > Cc: Jiri Olsa <jolsa@...nel.org>
> > ---
> >  include/asm-generic/rqspinlock.h | 2 +-
> >  kernel/bpf/rqspinlock.c          | 1 -
> >  2 files changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/include/asm-generic/rqspinlock.h b/include/asm-generic/rqspinlock.h
> > index 6d4244d643df..eac2dcd31b83 100644
> > --- a/include/asm-generic/rqspinlock.h
> > +++ b/include/asm-generic/rqspinlock.h
> > @@ -28,7 +28,7 @@ struct rqspinlock {
> >   */
> >  struct bpf_res_spin_lock {
> >         u32 val;
> > -};
> > +} __aligned(__alignof__(struct rqspinlock));
> 
> I don't follow.
> In the next patch you do:
> 
> typedef struct {
> - int counter;
> + int __aligned(sizeof(int)) counter;
> } atomic_t;
> 
> so it was 4 and still 4 ?
> Are you saying 'int' on m68k is not 4 byte aligned by default,
> so you have to force 4 byte align?
> 

Right. __alignof(int) == 2 on m68k.

> >  struct qspinlock;
> >  #ifdef CONFIG_QUEUED_SPINLOCKS
> > diff --git a/kernel/bpf/rqspinlock.c b/kernel/bpf/rqspinlock.c
> > index 338305c8852c..a88a0e9749d7 100644
> > --- a/kernel/bpf/rqspinlock.c
> > +++ b/kernel/bpf/rqspinlock.c
> > @@ -671,7 +671,6 @@ __bpf_kfunc int bpf_res_spin_lock(struct bpf_res_spin_lock *lock)
> >         int ret;
> >
> >         BUILD_BUG_ON(sizeof(rqspinlock_t) != sizeof(struct bpf_res_spin_lock));
> > -       BUILD_BUG_ON(__alignof__(rqspinlock_t) != __alignof__(struct bpf_res_spin_lock));
> 
> Why delete it? Didn't you make them equal in the above hunk?
> 

I deleted it because it's tautological. I think "do not repeat yourself" 
applies here.