On Thu, Dec 18, 2025 at 06:09:42AM -1000, Tejun Heo <[email protected]> wrote: > On Thu, Dec 18, 2025 at 03:09:32PM +0800, Chen Ridong wrote: > > Note that this level may already be used in existing BPF programs (e.g., > > tools/testing/selftests/bpf/progs/task_ls_uptr.c). Do we need to consider > > compatibility here? > > That's a good point.
I wouldn't be concerned about this particular aspect. The commit
e6ac2450d6dee ("bpf: Support bpf program calling kernel function")
excludes ABIs, the example program uses ksyms (not kfuncs), so there
could even apply Documentation/process/stable-api-nonsense.rst.
OTOH, the semantics of level is unchanged for BPF helpers (that are the
official API).
> Is __counted_by instrumentation tied to some compiler flag? If so,
> might as well make it an optional extra field specifically for the
> annotation rather than changing the meaning of an existing field.
Honestly, I can see benefit mainly in the first patch of the series
(posted the rest for discussion).
I'd like to ask Gustavo whether __counted_by here buys us anything or
whether it's more useful in other parts of kernel (e.g. flexible
allocations in networking code with outer sources of data).
Thanks,
Michal
signature.asc
Description: PGP signature
