BPF List
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: Jiri Olsa <olsajiri@gmail.com>,
	ast@kernel.org, andrii@kernel.org, daniel@iogearbox.net,
	martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org,
	yonghong.song@linux.dev, john.fastabend@gmail.com,
	kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com,
	mykolal@fb.com, bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next] selftests/bpf: add btf dedup test covering module BTF dedup
Date: Tue, 24 Jun 2025 13:48:08 +0200	[thread overview]
Message-ID: <aFqQeGG-vXEAldRA@krava> (raw)
In-Reply-To: <769e1fb7-d4b2-47cb-b71d-7db2168cb5aa@oracle.com>

On Fri, Jun 20, 2025 at 04:41:48PM +0100, Alan Maguire wrote:
> On 20/06/2025 14:51, Jiri Olsa wrote:
> > On Fri, Jun 20, 2025 at 03:34:14PM +0200, Jiri Olsa wrote:
> >> On Wed, Apr 30, 2025 at 02:42:49PM +0100, Alan Maguire wrote:
> >>> Recently issues were observed with module BTF deduplication failures
> >>> [1].  Add a dedup selftest that ensures that core kernel types are
> >>> referenced from split BTF as base BTF types.  To do this use bpf_testmod
> >>> functions which utilize core kernel types, specifically
> >>>
> >>> ssize_t
> >>> bpf_testmod_test_write(struct file *file, struct kobject *kobj,
> >>>                        struct bin_attribute *bin_attr,
> >>>                        char *buf, loff_t off, size_t len);
> >>>
> >>> __bpf_kfunc struct sock *bpf_kfunc_call_test3(struct sock *sk);
> >>>
> >>> __bpf_kfunc void bpf_kfunc_call_test_pass_ctx(struct __sk_buff *skb);
> >>>
> >>> For each of these ensure that the types they reference -
> >>> struct file, struct kobject, struct bin_attr etc - are in base BTF.
> >>> Note that because bpf_testmod.ko is built with distilled base BTF
> >>> the associated reference types - i.e. the PTR that points at a
> >>> "struct file" - will be in split BTF.  As a result the test resolves
> >>> typedef and pointer references and verifies the pointed-at or
> >>> typedef'ed type is in base BTF.  Because we use BTF from
> >>> /sys/kernel/btf/bpf_testmod relocation has occurred for the
> >>> referenced types and they will be base - not distilled base - types.
> >>>
> >>> For large-scale dedup issues, we see such types appear in split BTF and
> >>> as a result this test fails.  Hence it is proposed as a test which will
> >>> fail when large-scale dedup issues have occurred.
> >>>
> >>> [1] https://lore.kernel.org/dwarves/CAADnVQL+-LiJGXwxD3jEUrOonO-fX0SZC8496dVzUXvfkB7gYQ@mail.gmail.com/
> >>>
> >>> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> >>
> >> hi Alan,
> >> this one started to fail in my tests.. it's likely some screw up in
> >> my environment, but I haven't found the cause yet, I'm using the
> >> pahole 1.30 .. just cheking if it's known issue already ;-)
> > 
> > hum, it might be my gcc-14 .. will upgrade
> >
> 
> hi Jiri, is it possible you were using the pre-dedup-fix pahole, i.e.
> the official 1.30, or a version without
> 
> commit 6362d1f1657e3381e3e622d70364145f72804504
> Author: Alan Maguire <alan.maguire@oracle.com>
> Date:   Tue Apr 29 20:49:05 2025 +0100
> 
>     pahole: Sync with libbpf mainline
> 
>     To pull in dedup fix in
> 
>     commit 8e64c387c942 ("libbpf: Add identical pointer detection to
> btf_dedup_is_equiv()")
> 
>     sync with latest libbpf.
> 
> ? That would mean you would hit the module dedup failure and the test
> would fail as a result. If that's the case, if you could try syncing to
> the "next" branch of pahole and see if it recurs, that would be great!
> Thanks!

yep, that helped, thank you

jirka

      reply	other threads:[~2025-06-24 11:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-30 13:42 [PATCH bpf-next] selftests/bpf: add btf dedup test covering module BTF dedup Alan Maguire
2025-04-30 21:30 ` Eduard Zingerman
2025-05-01 21:10 ` patchwork-bot+netdevbpf
2025-06-20 13:34 ` Jiri Olsa
2025-06-20 13:51   ` Jiri Olsa
2025-06-20 15:41     ` Alan Maguire
2025-06-24 11:48       ` Jiri Olsa [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aFqQeGG-vXEAldRA@krava \
    --to=olsajiri@gmail.com \
    --cc=alan.maguire@oracle.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=kpsingh@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mykolal@fb.com \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox