Re: Supporting New Memory Barrier Types in BPF

Peilin Ye
2024-08-08T20:59:54Z

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