Re: [PATCH bpf-next] bpf, riscv: Register extable entries at probe insn call sites

[Chen Pei <cp0613@linux.alibaba.com>]

> This looks like a bug fix for the fragile mode-based filtering in
> add_exception_handler(). Should this include:
>
>   Fixes: b4757714cc63 ("bpf, riscv: Add support for signed arena loads")

No Fixes tag, because the mode/class collision has never been a live
bug in any released tree. b4757714cc63 introduced both the
BPF_PROBE_MEM32SX support and the LDX class guard in the mode gate, in
the same commit, precisely to keep plain atomics (which share the 0xc0
mode value) out of the exception table. Its commit message says so
explicitly:

  "Since BPF_PROBE_MEM32SX shares its mode value (0xc0) with
   BPF_ATOMIC, the gate accepts it only for LDX class instructions so
   that plain atomic instructions do not register exception table
   entries."

For context: I noticed this fragile shared-state gate while working on
v1 of "bpf, riscv: Add support for signed arena loads", where the class
guard was added as a preventive measure. This patch now follows up with
the actual cleanup, making the registration decision explicit at each
call site so future probe modes cannot silently collide with legitimate
encodings.

Also, regarding sashiko-bot's separate concern about BPF_PROBE_ATOMIC
cmpxchg without ZACAS: that path is unreachable, as arena BPF_CMPXCHG
is already gated on ZACAS by bpf_jit_supports_insn(), and
add_exception_handler() resets its offsets after every registration,
so stale offsets cannot be consumed. A separate fix I have prepared,
"bpf, riscv: Make arena support depend on ZACAS", further rejects
arena map creation on non-ZACAS systems altogether.

Best regards,
Pei