All of lore.kernel.org
 help / color / mirror / Atom feed
From: KaFai Wan <kafai.wan@linux.dev>
To: Tiezhu Yang <yangtiezhu@loongson.cn>,
	Leon Hwang <leon.hwang@linux.dev>,
	sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>
Subject: Re: [PATCH bpf-next v7 1/2] bpf: Introduce jit_required flag and refactor kfunc path
Date: Sat, 04 Jul 2026 09:17:45 +0800	[thread overview]
Message-ID: <f9c2301fbc1f0976a0438d81a8ed694a9b348e5a.camel@linux.dev> (raw)
In-Reply-To: <c56c20eb-00f9-046e-70a4-261499d0f2ae@loongson.cn>

On Fri, 2026-07-03 at 23:53 +0800, Tiezhu Yang wrote:
> On 7/3/26 22:14, Leon Hwang wrote:
> > On 2026/7/3 14:59, Tiezhu Yang wrote:
> > [...]
> > > > > ```
> > > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > > > index f496b45b9da4..1f5824c1c691 100644
> > > > > --- a/kernel/bpf/verifier.c
> > > > > +++ b/kernel/bpf/verifier.c
> > > > > @@ -2772,7 +2772,7 @@ int bpf_add_kfunc_call(struct bpf_verifier_env
> > > > > *env, u32 func_id, u16 offset)
> > > > > 
> > > > >    bool bpf_prog_has_kfunc_call(const struct bpf_prog *prog)
> > > > >    {
> > > > > -       return !!prog->aux->kfunc_tab;
> > > > > +       return prog->jit_required && !!prog->aux->kfunc_tab;
> > > > 
> > > > 
> > > > When 'prog->jit_required' is used for JIT-inlineable helper call, this
> > > > change could also cause false positive for the above pruned kfunc case.
> > > > 
> > > > If you don't want bpf_fixup_call_args() rejects the program with -EINVAL
> > > > for the pruned kfunc case, suggest moving 'if (!func_id && !offset)'
> > > > before the tab allocation in bpf_add_kfunc_call().
> > > 
> > > How about this:
> > > 
> > > ```
> > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > index 25aea4271cd0..c34cc524651a 100644
> > > --- a/kernel/bpf/verifier.c
> > > +++ b/kernel/bpf/verifier.c
> > > @@ -2770,7 +2770,7 @@ int bpf_add_kfunc_call(struct bpf_verifier_env
> > > *env, u32 func_id, u16 offset)
> > > 
> > >   bool bpf_prog_has_kfunc_call(const struct bpf_prog *prog)
> > >   {
> > > -       return !!prog->aux->kfunc_tab;
> > > +       return prog->aux->kfunc_tab && prog->aux->kfunc_tab->nr_descs > 0;
> > 
> > 
> > NIT: drop '> 0'
> > 
> > Looks better.
> 
> OK, will do it in v8.
> 
> > 
> > >   }
> > > 
> > >   static int add_subprog_and_kfunc(struct bpf_verifier_env *env)
> > > ```
> > > IMO, there are no side effects for the following four cases:
> > > 
> > > 1. Pure JIT-inlined Helper
> > > 2. Pure Pruned kfunc
> > > 3. Pruned kfunc + Inlined Helper
> > > 4. Active (Unpruned) kfunc
> > > 
> > 
> > This change allows pruned kfunc + interpreter fallback and pruned kfunc
> > + bpf_fixup_call_args(), when CONFIG_BPF_JIT_ALWAYS_ON is off.
> > 
> > Does it look like a pre-existing issue?
> 
> I think so.

no, it's not. for kfunc insn, ->imm means btf_id and ->off leads to fd of btf file.
we replace ->imm to actual address and reject invalid kfunc in bpf_fixup_kfunc_call(). 

all pruned kfuncs allowed in bpf_add_kfunc_call() are rejected in bpf_fixup_kfunc_call(), before
call bpf_fixup_call_args(), no pruned kfuncs fall back to the interpreter.

I think we can set ->jit_required at the entry of bpf_add_kfunc_call() instead of end, make less
confusion of AI.

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index d46f7db20d8f..4f7b43ab3729 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2713,6 +2713,7 @@ int bpf_add_kfunc_call(struct bpf_verifier_env *env, u32 func_id, u16 offset)
 			return -ENOMEM;
 		prog_aux->kfunc_tab = tab;
 	}
+	env->prog->jit_required = 1;
 
 	/* func_id == 0 is always invalid, but instead of returning an error, be
 	 * conservative and wait until the code elimination pass before returning

> 
> > 
> > Pls read "Support kernel module function calls from eBPF" [1] to
> > understand the background of introducing func_id=0 kfunc.
> > 
> > [1] https://lore.kernel.org/bpf/20211002011757.311265-1-memxor@gmail.com/
> > 
> > Thanks,
> > Leon
> 
> Thanks,
> Tiezhu
> 

-- 
Thanks,
KaFai

  reply	other threads:[~2026-07-04  1:18 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02 14:36 [PATCH bpf-next v7 0/2] Introduce jit_required to prevent a kernel panic Tiezhu Yang
2026-07-02 14:36 ` [PATCH bpf-next v7 1/2] bpf: Introduce jit_required flag and refactor kfunc path Tiezhu Yang
2026-07-02 14:58   ` sashiko-bot
2026-07-03  2:57     ` Tiezhu Yang
2026-07-03  5:24       ` Leon Hwang
2026-07-03  6:59         ` Tiezhu Yang
2026-07-03 14:14           ` Leon Hwang
2026-07-03 15:53             ` Tiezhu Yang
2026-07-04  1:17               ` KaFai Wan [this message]
2026-07-03 13:51       ` KaFai Wan
2026-07-03 15:56         ` Tiezhu Yang
2026-07-04  3:23           ` KaFai Wan
2026-07-03 13:55   ` KaFai Wan
2026-07-03 16:14     ` Tiezhu Yang
2026-07-04  1:57       ` KaFai Wan
2026-07-06  0:56         ` Tiezhu Yang
2026-07-06  3:59           ` Leon Hwang
2026-07-06  4:27             ` Tiezhu Yang
2026-07-06 10:58             ` KaFai Wan
2026-07-04  2:05       ` KaFai Wan
2026-07-02 14:36 ` [PATCH bpf-next v7 2/2] bpf: Reject programs with inlined helpers if JIT is unavailable Tiezhu Yang
2026-07-02 14:57   ` sashiko-bot
2026-07-03  4:14     ` Tiezhu Yang

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=f9c2301fbc1f0976a0438d81a8ed694a9b348e5a.camel@linux.dev \
    --to=kafai.wan@linux.dev \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=leon.hwang@linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yangtiezhu@loongson.cn \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.