From: Menglong Dong <menglong.dong@linux.dev>
To: Menglong Dong <menglong8.dong@gmail.com>,
ast@kernel.org, Eduard Zingerman <eddyz87@gmail.com>
Cc: 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, jiang.biao@linux.dev,
x86@kernel.org, hpa@zytor.com, netdev@vger.kernel.org,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next] bpf, x86: inline bpf_get_current_task() for x86_64
Date: Tue, 30 Dec 2025 14:33:53 +0800 [thread overview]
Message-ID: <6448186.lOV4Wx5bFT@7940hx> (raw)
In-Reply-To: <0f0bd124a42723acf87b427cc69356a0e4b1e339.camel@gmail.com>
On 2025/12/30 03:58 Eduard Zingerman <eddyz87@gmail.com> write:
> On Thu, 2025-12-25 at 18:44 +0800, Menglong Dong wrote:
> > Inline bpf_get_current_task() and bpf_get_current_task_btf() for x86_64
> > to obtain better performance. The instruction we use here is:
> >
> > 65 48 8B 04 25 [offset] // mov rax, gs:[offset]
> >
> > Not sure if there is any side effect here.
> >
> > Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
> > ---
>
> The change makes sense to me.
> Could you please address the compilation error reported by kernel test robot?
Yeah, I'll send a V2 later.
> Could you please also add a tests case using __jited annotation like
> in verifier_ldsx.c?
OK, sounds nice.
>
> > arch/x86/net/bpf_jit_comp.c | 33 +++++++++++++++++++++++++++++++++
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> > index b69dc7194e2c..7f38481816f0 100644
> > --- a/arch/x86/net/bpf_jit_comp.c
> > +++ b/arch/x86/net/bpf_jit_comp.c
> > @@ -1300,6 +1300,19 @@ static void emit_st_r12(u8 **pprog, u32 size, u32 dst_reg, int off, int imm)
> > emit_st_index(pprog, size, dst_reg, X86_REG_R12, off, imm);
> > }
> >
> > +static void emit_ldx_percpu_r0(u8 **pprog, const void __percpu *ptr)
> > +{
> > + u8 *prog = *pprog;
> > +
> > + /* mov rax, gs:[offset] */
> > + EMIT2(0x65, 0x48);
> > + EMIT2(0x8B, 0x04);
> > + EMIT1(0x25);
> > + EMIT((u32)(unsigned long)ptr, 4);
> > +
> > + *pprog = prog;
> > +}
> > +
> > static int emit_atomic_rmw(u8 **pprog, u32 atomic_op,
> > u32 dst_reg, u32 src_reg, s16 off, u8 bpf_size)
> > {
> > @@ -2435,6 +2448,15 @@ st: if (is_imm8(insn->off))
> > case BPF_JMP | BPF_CALL: {
> > u8 *ip = image + addrs[i - 1];
> >
> > + if (insn->src_reg == 0 && (insn->imm == BPF_FUNC_get_current_task ||
> > + insn->imm == BPF_FUNC_get_current_task_btf)) {
> > + if (IS_ENABLED(CONFIG_USE_X86_SEG_SUPPORT))
> > + emit_ldx_percpu_r0(&prog, &const_current_task);
> > + else
> > + emit_ldx_percpu_r0(&prog, ¤t_task);
>
> Nit: arch/x86/include/asm/current.h says that current_task and const_current_task are aliases.
> In that case, why would we need two branches here?
It's not need here. I were not familiar with the per-cpu variable
before, and didn't realize it.
And it seems that the gs register is only used in the
CONFIG_USE_X86_SEG_SUPPORT case, which is the common case.
So maybe we can support it for this case only. For the
!CONFIG_USE_X86_SEG_SUPPORT case, let me do more analysis to
see if we can support it easily.
Thanks!
Menglong Dong
>
> > + break;
> > + }
> > +
> > func = (u8 *) __bpf_call_base + imm32;
> > if (src_reg == BPF_PSEUDO_CALL && tail_call_reachable) {
> > LOAD_TAIL_CALL_CNT_PTR(stack_depth);
> > @@ -4067,3 +4089,14 @@ bool bpf_jit_supports_timed_may_goto(void)
> > {
> > return true;
> > }
> > +
> > +bool bpf_jit_inlines_helper_call(s32 imm)
> > +{
> > + switch (imm) {
> > + case BPF_FUNC_get_current_task:
> > + case BPF_FUNC_get_current_task_btf:
> > + return true;
> > + default:
> > + return false;
> > + }
> > +}
>
prev parent reply other threads:[~2025-12-30 6:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-25 10:44 [PATCH bpf-next] bpf, x86: inline bpf_get_current_task() for x86_64 Menglong Dong
2025-12-26 4:16 ` kernel test robot
2025-12-29 19:58 ` Eduard Zingerman
2025-12-30 6:33 ` 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=6448186.lOV4Wx5bFT@7940hx \
--to=menglong.dong@linux.dev \
--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=jiang.biao@linux.dev \
--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 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.