Re: [PATCH bpf-next v3 2/9] bpf: Support __arena and __arena_nullable on struct_ops arguments

Thank you for your contribution! Sashiko AI review found 3 potential issue(=
s) to consider:
- [High] The `__arena_nullable` BTF parameter suffix is erroneously process=
ed as `__nullable` due to substring matching, breaking `PTR_TO_ARENA` seman=
tics.
- [High] Attaching tracing programs (fentry/fexit) to struct_ops programs w=
ith arena arguments causes them to receive 32-bit user-space offsets typed =
as valid kernel pointers, leading to SMAP violations and kernel panics.
- [Low] Modified multi-line comments do not conform to the required BPF sub=
system comment style.
--

--- Patch [2]: [PATCH bpf-next v3 2/9] bpf: Support __arena and __arena_nul=
lable on struct_ops arguments ---
Note: The format of this review has been altered due to system restrictions=
 on
reciting original code. Instead of inline diff quotes, this report provides=
 a
free-form summary of the findings.

commit 0582d11e29a7b343a06709e7d3f0cdcc15655dcc
Author: Tejun Heo <[email protected]>
Subject: bpf: Support __arena and __arena_nullable on struct_ops arguments

This patch adds support for the __arena and __arena_nullable suffixes on
struct_ops arguments. This allows callbacks to declare parameters as arena
pointers, while the kernel caller passes the kernel arena address and the
trampoline handles the conversion.

[Severity: High]
In kernel/bpf/bpf_struct_ops.c within prepare_arg_info(), does the if/else
chain incorrectly prioritize the shorter suffix? Because
btf_param_match_suffix() matches the end of the parameter name, a parameter
ending in __arena_nullable also matches the shorter __nullable suffix.

Since the code checks for the nullable condition first, will this cause
__arena_nullable parameters to be incorrectly typed as PTR_MAYBE_NULL and
PTR_TO_BTF_ID rather than PTR_TO_ARENA? This seems like it could cause the
trampoline to skip the arena pointer conversion, passing a raw kernel
pointer instead, and potentially leading to verifier errors if used with a
non-struct pointer.

[Severity: Low]
This isn't a bug, but in kernel/bpf/bpf_struct_ops.c within
prepare_arg_info(), the modified multi-line comments appear to retain the
older kernel comment style where text follows the opening delimiter on the
same line.

Does the BPF subsystem require multi-line comments to have the opening
delimiter on its own line, even when modifying existing comments in a file
that previously used the old style?

[Severity: High]
In kernel/bpf/trampoline.c within bpf_trampoline_update(), does the
defensive check evaluate the wrong program's context arguments? The code
appears to check the attached tracing program (fentry/fexit) for arena
arguments rather than the target struct_ops program.

Since tracing programs do not have their ctx_arg_info initialized, could
this allow them to successfully attach to struct_ops programs that have
arena arguments?

If so, during verification in kernel/bpf/btf.c at btf_ctx_access(), the
tracing program's context argument would be typed as a standard
PTR_TO_BTF_ID because its ctx_arg_info_size is zero. At runtime, the
struct_ops trampoline would convert the kernel pointer to a 32-bit arena
offset, which the tracing program would receive and potentially dereference
as a standard kernel pointer. Could this sequence lead to SMAP violations
and kernel panics?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803125115.2264=
[email protected]?part=3D2