Re: Supporting New Memory Barrier Types in BPF

[Peilin Ye <yepeilin@google.com>]

On Mon, Sep 16, 2024 at 09:14:02PM +0000, Peilin Ye wrote:
> 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)?

Can we instead use the unused higher bits of bpf_insn::imm as a scratch
pad?                                                   ^^^

For example, instead of letting the verifier change bpf_insn::code from
BPF_ATOMIC to BPF_PROBE_ATOMIC, keep it as-is, but set the highest bit
in bpf_insn::imm to let the JIT know it is a "_PROBE_" instruction, and
there's a corresponding entry in the exception table.

Thanks,
Peilin Ye