BPF List
 help / color / mirror / Atom feed
From: Menglong Dong <menglong.dong@linux.dev>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Menglong Dong <menglong8.dong@gmail.com>,
	andrii@kernel.org, ast@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,
	jolsa@kernel.org, bpf@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next] libbpf: skip compat check for session kfuncs
Date: Tue, 24 Feb 2026 09:43:57 +0800	[thread overview]
Message-ID: <5968298.DvuYhMxLoT@7940hx> (raw)
In-Reply-To: <CAEf4BzYJPue8VN59buLAaxL_SfbnHQQXs7nQn6_2t6=E_CppvQ@mail.gmail.com>

On 2026/2/24 03:09 Andrii Nakryiko <andrii.nakryiko@gmail.com> write:
> On Sun, Feb 22, 2026 at 6:16 AM Menglong Dong <menglong.dong@linux.dev> wrote:
> >
> > On 2026/2/12 01:20, Andrii Nakryiko wrote:
> > > On Wed, Feb 11, 2026 at 4:57 AM Menglong Dong <menglong8.dong@gmail.com> wrote:
> > > >
> > > > The function prototype of bpf_session_{cookie,is_return} is changed in
> > > > the commit 8fe4dc4f6456 ("bpf: change prototype of
> > > > bpf_session_{cookie,is_return}"), which is not friendly to the old kernel,
> > > > as the libbpf will fail on the compatible checking.
> > > >
> > > > Therefore, let's skip the checking of bpf_session_{cookie,is_return} in
> > > > libbpf, and just let the kernel do the checking.
> > > >
> > > > Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
> > > > ---
> > > >  tools/lib/bpf/libbpf.c | 31 ++++++++++++++++++++-----------
> > > >  1 file changed, 20 insertions(+), 11 deletions(-)
> > > >
> > >
> > > This is not the way. Use bpf_ksym_exists() check and have custom
> > > legacy bpf_session_cookie___legacy() definition with old prototype.
> > > You can then detect whether
> > > bpf_ksym_exists(bpf_session_cookie___legacy) is true and use the
> > > legacy version, otherwise use the current version.
> >
> > Great! I found that there are already similar usages in kernel.
> > I did some tests, and it works well. Thanks!
> >
> > BTW, do you think that if we need do some wrapper for bpf_session_{cookie,is_return}
> > like this in case that someone else don't know the compatible problem?
> >
> > extern bool bpf_session_is_return___legacy(void) __weak __ksym;
> > extern __u64 *bpf_session_cookie___legacy(void) __weak __ksym;
> >
> >
> > #define bpf_session_is_return(ctx)                                                              \
> >         (bpf_ksym_exists(bpf_session_is_return___legacy) ? bpf_session_is_return___legacy() :   \
> >                                                            bpf_session_is_return(ctx))
> > #define bpf_session_cookie(ctx)                                                         \
> >         (bpf_ksym_exists(bpf_session_cookie___legacy) ? bpf_session_cookie___legacy() : \
> >                                                         bpf_session_cookie(ctx))
> >
> 
> I'd like to avoid carrying this in libbpf forever, tbh. One reason we
> decided to break bpf_session_xxx() helpers is because almost no one is
> using them in any serious capacity, so I'm thinking it's fine to just
> have this workaround live in your code base as an early session
> adopter.

OK!

> 
> > Thanks!
> > Menglong Dong
> >
> > >
> > > pw-bot: cr
> > >
> > >
> > > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > > > index 0c8bf0b5cce4..71bdd1c1ac39 100644
> > > > --- a/tools/lib/bpf/libbpf.c
> > > > +++ b/tools/lib/bpf/libbpf.c
> > > > @@ -8557,6 +8557,12 @@ static int find_ksym_btf_id(struct bpf_object *obj, const char *ksym_name,
> > > >         return id;
> > > >  }
> > > >
> > > > +static bool kfunc_skip_compat_check(const char *name)
> > > > +{
> > > > +       return name && (strcmp(name, "bpf_session_cookie") == 0 ||
> > > > +                       strcmp(name, "bpf_session_is_return") == 0);
> > > > +}
> > > > +
> > > >  static int bpf_object__resolve_ksym_var_btf_id(struct bpf_object *obj,
> > > >                                                struct extern_desc *ext)
> > > >  {
> > > > @@ -8617,12 +8623,13 @@ static int bpf_object__resolve_ksym_func_btf_id(struct bpf_object *obj,
> > > >         struct module_btf *mod_btf = NULL;
> > > >         const struct btf_type *kern_func;
> > > >         struct btf *kern_btf = NULL;
> > > > +       const char *kfunc_name;
> > > >         int ret;
> > > >
> > > >         local_func_proto_id = ext->ksym.type_id;
> > > >
> > > > -       kfunc_id = find_ksym_btf_id(obj, ext->essent_name ?: ext->name, BTF_KIND_FUNC, &kern_btf,
> > > > -                                   &mod_btf);
> > > > +       kfunc_name = ext->essent_name ?: ext->name;
> > > > +       kfunc_id = find_ksym_btf_id(obj, kfunc_name, BTF_KIND_FUNC, &kern_btf, &mod_btf);
> > > >         if (kfunc_id < 0) {
> > > >                 if (kfunc_id == -ESRCH && ext->is_weak)
> > > >                         return 0;
> > > > @@ -8634,16 +8641,18 @@ static int bpf_object__resolve_ksym_func_btf_id(struct bpf_object *obj,
> > > >         kern_func = btf__type_by_id(kern_btf, kfunc_id);
> > > >         kfunc_proto_id = kern_func->type;
> > > >
> > > > -       ret = bpf_core_types_are_compat(obj->btf, local_func_proto_id,
> > > > -                                       kern_btf, kfunc_proto_id);
> > > > -       if (ret <= 0) {
> > > > -               if (ext->is_weak)
> > > > -                       return 0;
> > > > +       if (!kfunc_skip_compat_check(kfunc_name)) {
> > > > +               ret = bpf_core_types_are_compat(obj->btf, local_func_proto_id,
> > > > +                                               kern_btf, kfunc_proto_id);
> > > > +               if (ret <= 0) {
> > > > +                       if (ext->is_weak)
> > > > +                               return 0;
> > > >
> > > > -               pr_warn("extern (func ksym) '%s': func_proto [%d] incompatible with %s [%d]\n",
> > > > -                       ext->name, local_func_proto_id,
> > > > -                       mod_btf ? mod_btf->name : "vmlinux", kfunc_proto_id);
> > > > -               return -EINVAL;
> > > > +                       pr_warn("extern (func ksym) '%s': func_proto [%d] incompatible with %s [%d]\n",
> > > > +                               ext->name, local_func_proto_id,
> > > > +                               mod_btf ? mod_btf->name : "vmlinux", kfunc_proto_id);
> > > > +                       return -EINVAL;
> > > > +               }
> > > >         }
> > > >
> > > >         /* set index for module BTF fd in fd_array, if unset */
> > > > --
> > > > 2.53.0
> > > >
> > >
> > >
> >
> >
> >
> >





      reply	other threads:[~2026-02-24  1:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-11 12:57 [PATCH bpf-next] libbpf: skip compat check for session kfuncs Menglong Dong
2026-02-11 17:20 ` Andrii Nakryiko
2026-02-22 10:59   ` Menglong Dong
2026-02-23 19:09     ` Andrii Nakryiko
2026-02-24  1:43       ` Menglong Dong [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=5968298.DvuYhMxLoT@7940hx \
    --to=menglong.dong@linux.dev \
    --cc=andrii.nakryiko@gmail.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=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=menglong8.dong@gmail.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