[PATCH bpf-next v5 1/6] bpf: Introduce load-acquire and store-release instructions
Alexei Starovoitov
alexei.starovoitov at gmail.com
Mon Mar 3 16:45:45 PST 2025
On Mon, Mar 3, 2025 at 4:39 PM Peilin Ye <yepeilin at google.com> wrote:
>
> Hi Alexei,
>
> On Mon, Mar 03, 2025 at 04:24:12PM -0800, Alexei Starovoitov wrote:
> > > switch (insn->imm) {
> > > @@ -7780,6 +7813,24 @@ static int check_atomic(struct bpf_verifier_env *env, struct bpf_insn *insn)
> > > case BPF_XCHG:
> > > case BPF_CMPXCHG:
> > > return check_atomic_rmw(env, insn);
> > > + case BPF_LOAD_ACQ:
> > > +#ifndef CONFIG_64BIT
> > > + if (BPF_SIZE(insn->code) == BPF_DW) {
> > > + verbose(env,
> > > + "64-bit load-acquires are only supported on 64-bit arches\n");
> > > + return -EOPNOTSUPP;
> > > + }
> > > +#endif
> >
> > Your earlier proposal of:
> > if (BPF_SIZE(insn->code) == BPF_DW && BITS_PER_LONG != 64) {
> >
> > was cleaner.
> > Why did you pick ifndef ?
>
> Likely overthinking, but I wanted to avoid this check at all for 64-bit
> arches, so it's just a little bit faster. Should I change it back to
> checking BITS_PER_LONG ?
In general #ifdef in .c is the last resort.
We avoid it when possible.
In core.c we probably cannot, but here we can.
So yes. please respin.
I bet the compiler will produce the exact same code.
More information about the linux-arm-kernel
mailing list