Re: Supporting New Memory Barrier Types in BPF

[Peilin Ye <yepeilin@google.com>]

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