On Thu, Aug 08, 2024 at 09:33:31AM -0700, Alexei Starovoitov wrote: > > > ldx/stx insns support MEM and MEMSX modifiers. > > > Adding MEM_ACQ_REL feels like a natural fit. Better name? > > > > Do we allow aliases? E.g., can we have "MEMACQ" for LDX and "MEMREL" > > for STX, but let them share the same numeric value? > > yes. See > #define BPF_ATOMIC 0xc0 /* atomic memory ops - op type in immediate */ > #define BPF_XADD 0xc0 /* exclusive add - legacy name */ > > but it has to be backward compatible. > > > Speaking of numeric value, out of curiosity: > > > > IMM 0 > > ABS 1 > > IND 2 > > MEM 3 > > MEMSX 4 > > ATOMIC 6 > > > > Was there a reason that we skipped 5? Is 5 reserved? > > See > /* unused opcode to mark special load instruction. Same as BPF_ABS */ > #define BPF_PROBE_MEM 0x20 > > /* unused opcode to mark special ldsx instruction. Same as BPF_IND */ > #define BPF_PROBE_MEMSX 0x40 > > /* unused opcode to mark special load instruction. Same as BPF_MSH */ > #define BPF_PROBE_MEM32 0xa0 > > it's used by the verifier when it remaps opcode to tell JIT. > It can be used, but then the internal opcode needs to change too. [...] > > It seems that nocsr BPF kfuncs are not supported yet. Do we have a > > schedule for it? > > Support for nocsr for kfuncs is being added. > Assume it's already available :) > It's not a blocker to add barrier kfuncs. Got it! I'll start cooking (kernel and LLVM) patches for "MEMACQ" and "MEMREL" (using 0x7) first. Thanks, Peilin Ye
