On 12/19/25 01:32, Michal Koutný wrote:
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).
Ideally, all structures containing a flexible-array member (FAM) should
be annotated. However, if this is too much of a hassle right now, I'd
say the priority is to avoid the -Wflex-array-member-not-at-end warnings,
first.
Thanks
-Gustavo
