Re: pahole next->master. Was: [PATCH bpf-next v1] selftests/bpf: Guard addr_space_cast code with __BPF_FEATURE_ADDR_SPACE_CAST

[Arnaldo Carvalho de Melo <acme@kernel.org>]

On Mon, Oct 27, 2025 at 11:58:43AM -0300, Arnaldo Carvalho de Melo wrote:
> On Thu, Oct 23, 2025 at 08:42:34AM -0700, Alexei Starovoitov wrote:
> > On Thu, Oct 23, 2025 at 12:50 AM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
> > > thanks, but version 1.30 didn't work in my tests - even pahole's master branch fails, only the next branch works...
> > >
> 
> > > It seems that the 'old' pahole parses some kfuncs incorrectly, for example bpf_dynptr_slice().
> l
> > Alan,
>  
> > the introduction of the 'next' branch screwed up the workflow for many people.
> > Let's remove it and merge everything into master.
> > People expect master branch to be the one where active development
> > is happening and the source of truth for the latest features.
> 
> My bad, I've been away for too long, next is supposed to be with things
> for a short while, testing for a few days, for CI consumption, then move
> to master, rinse repeat.
> 
> I think we should go back to that model.

The difference is small but can explain as has changes to the btf
loader, and the reporter, as I now checked the whole thread, says that
'next' works for him, so I'll move what is in 'next' to 'master' now.

Just for reference since I had done it, my investigation is below.

- Arnaldo

⬢ [acme@toolbx pahole]$ git remote update korg
Fetching korg
⬢ [acme@toolbx pahole]$ 
⬢ [acme@toolbx pahole]$ git remote -v | grep korg
korg	https://git.kernel.org/pub/scm/devel/pahole/pahole.git (fetch)
korg	https://git.kernel.org/pub/scm/devel/pahole/pahole.git (push)
⬢ [acme@toolbx pahole]$ git diff --stat korg/master korg/next 
warning: refname 'korg/next' is ambiguous.
 .github/scripts/build-pahole.sh      | 23 +++++++++++++++++++++++
 .github/scripts/compare-functions.sh | 30 ++++++++++++++++++++++++++++++
 .github/workflows/test.yml           |  4 ++--
 .github/workflows/vmtest.yml         |  4 ++++
 CMakeLists.txt                       |  5 -----
 README                               |  4 ++++
 btf_loader.c                         | 23 ++++++++++++++++++++---
 dwarves_fprintf.c                    |  2 +-
 8 files changed, 84 insertions(+), 11 deletions(-)
⬢ [acme@toolbx pahole]$

Related to btf bitfields:

diff --git a/btf_loader.c b/btf_loader.c
index f4f9f65289b5acac..64ea68022ab04e60 100644
--- a/btf_loader.c
+++ b/btf_loader.c
@@ -645,9 +645,15 @@ static int class__fixup_btf_bitfields(const struct conf_load *conf, struct tag *
                pos->byte_size = tag__size(type, cu);
                pos->bit_size = pos->byte_size * 8;
 
-               /* if BTF data is incorrect and has size == 0, skip field,
-                * instead of crashing */
+               /* If the BTF data is incorrect and has size == 0, skip field
+                * instead of crashing. However the field can be a zero or
+                * variable-length array and we still need to infer alignment.
+                */
                if (pos->byte_size == 0) {
+                       pos->alignment = class__infer_alignment(conf,
+                                                               pos->byte_offset,
+                                                               tag__natural_alignment(type, cu),
+                                                               smallest_offset);
                        continue;
                }
 
@@ -672,7 +678,18 @@ static int class__fixup_btf_bitfields(const struct conf_load *conf, struct tag *
                                                        pos->byte_offset,
                                                        tag__natural_alignment(type, cu),
                                                        smallest_offset);
-               smallest_offset = pos->byte_offset + pos->byte_size;
+
+               /* Compute the smallest offset between this field and the next
+                * one.
+                *
+                * In case of bitfields we need to take into account the
+                * actual size being used instead of the underlying type one as
+                * it could be larger, otherwise we could miss a hole.
+                */
+               smallest_offset = pos->byte_offset;
+               smallest_offset += pos->bitfield_size ?
+                       (pos->bitfield_offset + pos->bitfield_size + 7) / 8 :
+                       pos->byte_size;
        }
 
        tag_type->alignment = class__infer_alignment(conf,