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.
