Re: [PATCH bpf-next v3 0/4] btf_encoder: emit type tags for bpf_arena pointers

Alan Maguire
2025-02-25T09:36:25Z

On 24/02/2025 20:32, Ihor Solodrai wrote:
> On 2/21/25 6:47 AM, Alan Maguire wrote:
>> On 19/02/2025 21:05, Ihor Solodrai wrote:
>>> This patch series implements emitting appropriate BTF type tags for
>>> argument and return types of kfuncs marked with KF_ARENA_* flags.
>>>
>>> For additional context see the description of BPF patch
>>> "bpf: define KF_ARENA_* flags for bpf_arena kfuncs" [1].
>>>
>>> The feature depends on recent changes in libbpf [2].
>>>
>>> [1] https://lore.kernel.org/bpf/20250206003148.2308659-1-ihor.solodrai@linux.dev/
>>> [2] https://lore.kernel.org/bpf/20250130201239.1429648-1-ihor.solodrai@linux.dev/
>>>
>>
>> hi Ihor, just realized that given that this change depends on recent
>> libbpf changes, we should look at updating the series to include a patch
>> updating our libbpf subproject checkpoint commit for libbpf to get those
>> changes for the case where the libbpf submodule is built (the default
>> these days). We should probably have a patch (pahole: sync with
>> libbpf-1.6) to cover this. An example of a subproject commit patch can
>> be found at
>>
>> https://lore.kernel.org/dwarves/20240729111317.140816-2-alan.maguire@oracle.com/
>>
>> However I don't think those bpf-next libbpf changes have been synced
>> with the github libbpf repo yet. If the next libbf sync won't be for a
>> while, I don't think this has to block this work - we could just note
>> that it needs to explicitly be built with latest v1.6 via shared library
>> for testing purposes in the interim - but if there's a sync planned soon
>> it'd be great to roll that in too.
>
> Hi Alan. I've just submitted a PR to sync libbpf with upstream.
> https://github.com/libbpf/libbpf/pull/886
>
> Will add a subproject commit patch.
>

Fantastic, thank you!

> Andrii suggested pahole could use __weak declarations of libbpf API
> and detect if they are linked at runtime. This way it's not necessary
> to check for libbpf version. There are just a few places where we
> currently do that.
>
> What do you think if I add patches for that too?
>

That would be great! The current approach of static build-time version
checking isn't ideal, especially for folks using a dynamically linked
libbpf.

Alan

> Thanks.
>
>>
>> Thanks!
>>
>> Alan
>>
>> > v2->v3:
>>> * Nits in patch #1
>>>
>>> v1->v2:
>>> * Rewrite patch #1 refactoring btf_encoder__tag_kfuncs(): now the
>>> post-processing step is removed entirely, and kfuncs are tagged in
>>> btf_encoder__add_func().
>>> * Nits and renames in patch #2
>>> * Add patch #4 editing man pages
>>>
>>> v2: https://lore.kernel.org/dwarves/20250212201552.1431219-1-ihor.solodrai@linux.dev/
>>> v1: https://lore.kernel.org/dwarves/20250207021442.155703-1-ihor.solodrai@linux.dev/
>>>
>>> Ihor Solodrai (4):
>>> btf_encoder: refactor btf_encoder__tag_kfuncs()
>>> btf_encoder: emit type tags for bpf_arena pointers
>>> pahole: introduce --btf_feature=attributes
>>> man-pages: describe attributes and remove reproducible_build
>>>
>>> btf_encoder.c | 279 +++++++++++++++++++++++----------------------
>>> dwarves.h | 1 +
>>> man-pages/pahole.1 | 7 +-
>>> pahole.c | 11 ++
>>> 4 files changed, 158 insertions(+), 140 deletions(-)
>>>
>>