Re: [PATCH bpf-next v2 6/6] docs, resolve_btfids: Document kfunc BTF annotation emission
Ihor Solodrai <[email protected]>
| Newsgroups | org.kernel.vger.bpf |
|---|---|
| Message-ID | <[email protected]> |
On 8/6/26 12:47 PM, Eduard Zingerman wrote: > On Wed, 2026-08-05 at 16:06 -0700, Ihor Solodrai wrote: > > ... > >> diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst >> index cbde86d082cc..c60fc574e8b0 100644 >> --- a/Documentation/bpf/kfuncs.rst >> +++ b/Documentation/bpf/kfuncs.rst >> @@ -472,6 +472,14 @@ type. An example is shown below:: >> } >> late_initcall(init_subsystem); >> >> +At kernel build time the ``resolve_btfids`` tool discovers all kfuncs from the >> +registered ``BTF_SET8_KFUNCS`` sets and emits their BTF annotations into the > > Note that this is a single occurrence of the word BTF_SET8_KFUNCS in > this .rst file. Also The wording "registered" is confusing as the > above code snippet shows the usage of register_btf_kfunc_id_set() > function, which is completely unrelated. > >> +kernel's BTF; these annotations were historically produced by pahole. For each > > I'd skip a note about pahole, it does not convey usable information. ack > >> +discovered kfunc ``resolve_btfids`` emits a ``bpf_kfunc`` BTF decl tag, a >> +``bpf_fastcall`` decl tag when the kfunc is flagged ``KF_FASTCALL``, and the >> +``address_space(1)`` type attribute on the return value and/or arguments flagged >> +``KF_ARENA_RET``, ``KF_ARENA_ARG1`` or ``KF_ARENA_ARG2`` (see section 2.8). >> + >> 2.7 Specifying no-cast aliases with ___init >> -------------------------------------------- >> >> diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst >> index 1ca8c5f73ad0..6d1dbe4abf0f 100644 >> --- a/Documentation/process/changes.rst >> +++ b/Documentation/process/changes.rst >> @@ -147,10 +147,9 @@ Since Linux 5.2, if CONFIG_DEBUG_INFO_BTF is selected, the build system >> generates BTF (BPF Type Format) from DWARF in vmlinux, a bit later from kernel >> modules as well. This requires pahole v1.22 or later. >> >> -Since Linux 7.0, kfuncs annotated with KF_IMPLICIT_ARGS require pahole v1.26 >> -or later. Without it, such kfuncs will have incorrect BTF prototypes in >> -vmlinux, causing BPF programs to fail to load with a "func_proto incompatible >> -with vmlinux" error. Many sched_ext kfuncs are affected. >> +Kfunc BTF annotations (the bpf_kfunc and bpf_fastcall decl tags and the arena >> +address_space(1) type attribute) are emitted in-tree by resolve_btfids from the >> +BTF_KFUNCS sets, so they no longer depend on a specific pahole version. > > Just drop the whole paragraph? hmm... yeah you're right > >> >> It is found in the 'dwarves' or 'pahole' distro packages or from >> https://fedorapeople.org/~acme/dwarves/. >> diff --git a/scripts/Makefile.btf b/scripts/Makefile.btf >> index a1812985a61a..717e76ce96a7 100644 >> --- a/scripts/Makefile.btf >> +++ b/scripts/Makefile.btf >> @@ -14,6 +14,9 @@ pahole-flags-$(call test-ge, $(pahole-ver), 125) += --skip_encoding_btf_inconsis >> else >> >> # Switch to using --btf_features for v1.26 and later. >> +# >> +# kfunc BTF annotations (bpf_kfunc/bpf_fastcall decl tags and the arena >> +# address_space(1) type attribute) are emitted by resolve_btfids, not pahole. > > What's the point of this comment? The point is to inform the reader "where did decl_tag_kfuncs go?". Question is whether the git log will be enough, or is a comment also appropriate? > >> pahole-flags-$(call test-ge, $(pahole-ver), 126) = -j$(JOBS) --btf_features=encode_force,var,float,enum64,decl_tag,type_tag,optimized_func,consistent_func >> >> pahole-flags-$(call test-ge, $(pahole-ver), 131) += --btf_features=layout > > ...