Re: Supporting New Memory Barrier Types in BPF

[Peilin Ye <yepeilin@google.com>]

Hi all,

LLVM changes for load-acquire and store-release are available for review
at: https://github.com/llvm/llvm-project/pull/108636

I've tentatively put them under -mcpu=v5.  Please take a look when you
have a chance.  Thanks!

I just noticed, however:

> On Thu, Aug 08, 2024 at 09:33:31AM -0700, Alexei Starovoitov wrote:
> > > 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.

There's also:

  /* unused opcode to mark special atomic instruction */
  #define BPF_PROBE_ATOMIC 0xe0

0xe0 is (7 << 5), so it seems like we've already run out of bits for
mode modifiers?  Can we delete these internal opcodes and re-implement
them in other ways, to make room for MEMACQ (MEMREL)?

Thanks,
Peilin Ye