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
> 
> ...
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.