From: Menglong Dong <menglong.dong@linux.dev>
To: Menglong Dong <menglong8.dong@gmail.com>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: ast@kernel.org, eddyz87@gmail.com, davem@davemloft.net,
dsahern@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, netdev@vger.kernel.org,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v6 1/2] bpf, x86: inline bpf_get_current_task() for x86_64
Date: Wed, 21 Jan 2026 09:58:10 +0800 [thread overview]
Message-ID: <10788751.nUPlyArG6x@7940hx> (raw)
In-Reply-To: <CAEf4BzYjbP4KwuVNT_pgjfXy=+7saEezmp1ck2L5txwtik5WYw@mail.gmail.com>
On 2026/1/21 09:23 Andrii Nakryiko <andrii.nakryiko@gmail.com> write:
> On Mon, Jan 19, 2026 at 11:06 PM Menglong Dong <menglong8.dong@gmail.com> wrote:
> >
> > Inline bpf_get_current_task() and bpf_get_current_task_btf() for x86_64
> > to obtain better performance.
> >
> > Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
> > Acked-by: Eduard Zingerman <eddyz87@gmail.com>
> > ---
> > v5:
> > - don't support the !CONFIG_SMP case
> >
> > v4:
> > - handle the !CONFIG_SMP case
> >
> > v3:
> > - implement it in the verifier with BPF_MOV64_PERCPU_REG() instead of in
> > x86_64 JIT.
> > ---
> > kernel/bpf/verifier.c | 22 ++++++++++++++++++++++
> > 1 file changed, 22 insertions(+)
> >
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 9de0ec0c3ed9..c4e2ffadfb1f 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -17739,6 +17739,10 @@ static bool verifier_inlines_helper_call(struct bpf_verifier_env *env, s32 imm)
> > switch (imm) {
> > #ifdef CONFIG_X86_64
> > case BPF_FUNC_get_smp_processor_id:
> > +#ifdef CONFIG_SMP
> > + case BPF_FUNC_get_current_task_btf:
> > + case BPF_FUNC_get_current_task:
> > +#endif
>
> Does this have to be x86-64 specific inlining? With verifier inlining
> and per_cpu instruction support it should theoretically work across
> all architectures that do support per-cpu instruction, no?
>
> Eduard pointed out [0] to me for why we have that x86-64 specific
> check. But looking at do_misc_fixups(), we have that early
> bpf_jit_inlines_helper_call(insn->imm)) check, so if some JIT has more
> performant inlining implementation, we will just do that.
>
> So it seems like we can just drop all that x86-64 specific logic and
> claim all three of these functions as inlinable, no?
>
> And even more. We can drop rather confusing
> verifier_inlines_helper_call() that duplicates the decision of which
> helpers can be inlined or not, and have:
The verifier_inlines_helper_call() is confusing, but I think we can't
remove the x86-64 checking. For example, some architecture
don't support BPF_FUNC_get_current_task both in
bpf_jit_inlines_helper_call() and verifier_inlines_helper_call(), which
means it can't be inline.
>
> if (env->prog->jit_requested && bpf_jit_supports_percpu_insn() {
> switch (insn->imm) {
> case BPF_FUNC_get_smp_processor_id:
> ...
> break;
> case BPF_FUNC_get_current_task_btf:
> case BPF_FUNC_get_current_task_btf:
> ...
> break;
> default:
> }
>
> And the decision about inlining will live in one place.
>
> Or am I missing some complications?
As Alexei said, the implement of "current" is architecture specific,
and the per-cpu variable "current_task" only exist on x86_64.
>
> And with all that, should we mark get_current_task and
> get_current_task_btf as __bpf_fastcall?
I think it make sense, and the I saw bpf_get_smp_processor_id does
such operation:
const struct bpf_func_proto bpf_get_smp_processor_id_proto = {
[...]
.allow_fastcall = true,
};
PS: I'm a little confused about the fast call. We inline many helper,
but it seems that bpf_get_smp_processor_id is the only one that
use the "allow_fastcall". Why? I'd better study harder.
Thanks!
Menglong Dong
>
>
> [0] https://lore.kernel.org/all/20240722233844.1406874-4-eddyz87@gmail.com/
>
> > return env->prog->jit_requested && bpf_jit_supports_percpu_insn();
> > #endif
> > default:
> > @@ -23319,6 +23323,24 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
> > insn = new_prog->insnsi + i + delta;
> > goto next_insn;
> > }
> > +
> > + /* Implement bpf_get_current_task() and bpf_get_current_task_btf() inline. */
> > + if ((insn->imm == BPF_FUNC_get_current_task || insn->imm == BPF_FUNC_get_current_task_btf) &&
> > + verifier_inlines_helper_call(env, insn->imm)) {
> > + insn_buf[0] = BPF_MOV64_IMM(BPF_REG_0, (u32)(unsigned long)¤t_task);
> > + insn_buf[1] = BPF_MOV64_PERCPU_REG(BPF_REG_0, BPF_REG_0);
> > + insn_buf[2] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_0, 0);
> > + cnt = 3;
> > +
> > + new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt);
> > + if (!new_prog)
> > + return -ENOMEM;
> > +
> > + delta += cnt - 1;
> > + env->prog = prog = new_prog;
> > + insn = new_prog->insnsi + i + delta;
> > + goto next_insn;
> > + }
> > #endif
> > /* Implement bpf_get_func_arg inline. */
> > if (prog_type == BPF_PROG_TYPE_TRACING &&
> > --
> > 2.52.0
> >
>
next prev parent reply other threads:[~2026-01-21 1:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 7:05 [PATCH bpf-next v6 0/2] bpf, x86: inline bpf_get_current_task() for x86_64 Menglong Dong
2026-01-20 7:05 ` [PATCH bpf-next v6 1/2] " Menglong Dong
2026-01-21 1:23 ` Andrii Nakryiko
2026-01-21 1:43 ` Alexei Starovoitov
2026-01-21 1:58 ` Menglong Dong [this message]
2026-01-21 3:10 ` Alexei Starovoitov
2026-01-21 3:37 ` Menglong Dong
2026-01-21 4:12 ` Andrii Nakryiko
2026-01-21 4:46 ` Alexei Starovoitov
2026-01-21 6:35 ` Andrii Nakryiko
2026-01-20 7:05 ` [PATCH bpf-next v6 2/2] selftests/bpf: test the jited inline of bpf_get_current_task Menglong Dong
2026-01-20 17:52 ` Eduard Zingerman
2026-01-21 1:05 ` Andrii Nakryiko
2026-01-21 1:28 ` Menglong Dong
2026-01-21 1:32 ` Eduard Zingerman
2026-01-21 3:03 ` Menglong Dong
2026-01-21 4:50 ` [PATCH bpf-next v6 0/2] bpf, x86: inline bpf_get_current_task() for x86_64 patchwork-bot+netdevbpf
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=10788751.nUPlyArG6x@7940hx \
--to=menglong.dong@linux.dev \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=hpa@zytor.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=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@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