Re: [PATCH bpf-next v1 00/14] resolve_btfids: Implement BTF tags emission for kfuncs

[Ihor Solodrai <ihor.solodrai@linux.dev>]

On 6/3/26 4:45 PM, Andrii Nakryiko wrote:
> On Mon, Jun 1, 2026 at 3:18 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>> BTF data for the kernel is generated through the following pipeline:
>>   * DWARF is emitted by the compiler
>>   * pahole reads in DWARF and produces BTF
>>   * resolve_btfids makes kernel-specific btf2btf transformation and
>>     patches .BTF_ids section
>>
>> This is orchestrated by link-vmlinux.sh, gen-btf.sh and Makefile.btf
>> in ./scripts directory.
>>
>> Historically kernel-specific BTF features were implemented in pahole,
>> and controlled by the feature flags. This requires kernel build
>> process to be aware of pahole version used for the build to set
>> correct runtime arguments for BTF encoding [1].
>>
>> This is a burden which can be alleviated by splitting kernel/module
>> BTF generation in two stages:
>>   1. Generic BTF generation from the kernel source code.
>>   2. Kernel-specific BTF modifications to support various BPF features.
>>
>> So far both stages were fused in pahole's BTF encoding. By moving
>> stage (2) in-tree, the dependency of kernel build on pahole can become
>> much more loose.
>>
>> Recent work [2] made it possible to do btf2btf transformations in
>> resolve_btfids, and it is already responsible for a few important BTF
>> modifications for the kernel:
>>   * .BTF.base generation for modules [3]
>>   * BTF sorting [4]
>>   * KF_IMPLICIT_ARGS support [5]
>>
>> This series continues the migration of kernel-specific BTF
>> transformations from pahole to resolve_btfids, implementing emission
>> of decl/type tags for the kfuncs and handling of the KF_ARENA_* flags.
>>
>> The implementation is idempotent with respect to BTF modifications: if
> 
> This sounds like an unnecessary complication. Can't we just control
> pahole through flags to guarantee there will be no kernel-specific
> information emitted?

Hi everyone.

I talked to Andrii off-list about this series last week and I'm in the
middle of preparing a v2, which is why I've been quiet in the thread.

The main v1->v2 design change from the discussion is to drop the
"ensure" pattern: just assume valid BTF on input. This requires
restructuring the series to preserve bisectability with respect to the
pahole flags.

I'll go through the messages now and reply where necessary. I'm going
to silently accept most of the nits I think.

Thanks!

> 
> 
>> input BTF already contains target tags, corresponding resolve_btfids
>> transformation is a noop. This allows for more flexibility in terms of
>> dependency on pahole. In particular, older pahole (without
>> decl_tag_kfuncs support, for example) can now be used in kbuild and
>> the resulting vmlinux BTF will contain properly tagged kfuncs
>> anyways. Conversely, if for whatever reason pahole emitted the same
>> tags, they will be properly skipped.
>>
>> [...]