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 12:09:11PM -0300, Arnaldo Carvalho de Melo wrote:
> 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().

> > > 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.

So I had some random 'korg/next' local branch and a 'korg' remote and
that messed up my analysis, there are more csets in the 'next' branch,
so I'm doing more tests, tomorrow I'll probably have more news.
 
- 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,