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
