Re: [PATCH bpf-next v2 4/9] bpf: Introduce load-acquire and store-release instructions

[Alexei Starovoitov]

On Fri, Feb 14, 2025 at 6:34 PM Peilin Ye <yepeilin@xxxxxxxxxx> wrote:
>
> > On Wed, Feb 12, 2025 at 09:55:43PM -0800, Alexei Starovoitov wrote:
> > > How about:
> > > #define BPF_LOAD_ACQ 2
> > > #define BPF_STORE_REL 3
> > >
> > > and only use them with BPF_MOV like
> > >
> > > imm = BPF_MOV | BPF_LOAD_ACQ - is actual load acquire
> > > imm = BPF_MOV | BPF_STORE_REL - release
>
> Based on everything discussed, should we proceed with the above
> suggestion?  Specifically:
>
>   #define BPF_LD_ST     BPF_MOV /* 0xb0 */

The aliasing still bothers me.
I hated doing it when going from cBPF to eBPF,
but we only had 8-bit to work with.
Here we have 32-bit.
Aliases make disassemblers trickier, since value no longer
translates to string as-is. It depends on the context.
There is probably no use for BPF_MOV operation in atomic
context, but by reusing BPF_ADD, BPF_XOR, etc in atomic
we signed up ourselves for all of alu ops.
That's why BPF_XCHG and BPF_CMPXCHG are outside
of alu op range.

So my preference is to do:
#define BPF_LOAD_ACQ 0x100
#define BPF_STORE_REL 0x110
#define BPF_CMPWAIT_RELAXED   0x120

and keep growing it.
We burn the first nibble, but so be it.