From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Leon Hwang <hffilwlqm@gmail.com>
Cc: <bpf@vger.kernel.org>, <ast@kernel.org>, <daniel@iogearbox.net>,
<andrii@kernel.org>, <jakub@cloudflare.com>, <iii@linux.ibm.com>,
<hengqi.chen@gmail.com>
Subject: Re: [RFC PATCH bpf-next v2 1/4] bpf, x64: Emit nops for X86_PATCH
Date: Tue, 5 Dec 2023 14:08:01 +0100 [thread overview]
Message-ID: <ZW8gsbqkJwC1x4Cs@boxer> (raw)
In-Reply-To: <20231011152725.95895-2-hffilwlqm@gmail.com>
On Wed, Oct 11, 2023 at 11:27:22PM +0800, Leon Hwang wrote:
> For next commit to reuse emit_nops(), move emit_nops() before
> emit_prologue().
>
> By the way, change memcpy(prog, x86_nops[5], X86_PATCH_SIZE) to
> emit_nops(&prog, X86_PATCH_SIZE).
I find the subject of the commit a bit bogus. Could you change it to
something like:
use emit_nops() to produce nop5 instead memcpy'ing x86_nops[5]
I also feel that you should be consistent and address other spots that are
the same as the one that you are touching in emit_prologue() - there are
two more from what i see.
>
> Signed-off-by: Leon Hwang <hffilwlqm@gmail.com>
> ---
> arch/x86/net/bpf_jit_comp.c | 41 ++++++++++++++++++-------------------
> 1 file changed, 20 insertions(+), 21 deletions(-)
>
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index 8c10d9abc2394..c2a0465d37da4 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -304,6 +304,25 @@ static void pop_callee_regs(u8 **pprog, bool *callee_regs_used)
> *pprog = prog;
> }
>
> +static void emit_nops(u8 **pprog, int len)
> +{
> + u8 *prog = *pprog;
> + int i, noplen;
> +
> + while (len > 0) {
> + noplen = len;
> +
> + if (noplen > ASM_NOP_MAX)
> + noplen = ASM_NOP_MAX;
> +
> + for (i = 0; i < noplen; i++)
> + EMIT1(x86_nops[noplen][i]);
> + len -= noplen;
> + }
> +
> + *pprog = prog;
> +}
> +
> /*
> * Emit x86-64 prologue code for BPF program.
> * bpf_tail_call helper will skip the first X86_TAIL_CALL_OFFSET bytes
> @@ -319,8 +338,7 @@ static void emit_prologue(u8 **pprog, u32 stack_depth, bool ebpf_from_cbpf,
> * but let's waste 5 bytes for now and optimize later
> */
> EMIT_ENDBR();
> - memcpy(prog, x86_nops[5], X86_PATCH_SIZE);
> - prog += X86_PATCH_SIZE;
> + emit_nops(&prog, X86_PATCH_SIZE);
> if (!ebpf_from_cbpf) {
> if (tail_call_reachable && !is_subprog)
> /* When it's the entry of the whole tailcall context,
> @@ -989,25 +1007,6 @@ static void detect_reg_usage(struct bpf_insn *insn, int insn_cnt,
> }
> }
>
> -static void emit_nops(u8 **pprog, int len)
> -{
> - u8 *prog = *pprog;
> - int i, noplen;
> -
> - while (len > 0) {
> - noplen = len;
> -
> - if (noplen > ASM_NOP_MAX)
> - noplen = ASM_NOP_MAX;
> -
> - for (i = 0; i < noplen; i++)
> - EMIT1(x86_nops[noplen][i]);
> - len -= noplen;
> - }
> -
> - *pprog = prog;
> -}
> -
> /* emit the 3-byte VEX prefix
> *
> * r: same as rex.r, extra bit for ModRM reg field
> --
> 2.41.0
>
next prev parent reply other threads:[~2023-12-05 13:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-11 15:27 [RFC PATCH bpf-next v2 0/4] bpf, x64: Fix tailcall hierarchy Leon Hwang
2023-10-11 15:27 ` [RFC PATCH bpf-next v2 1/4] bpf, x64: Emit nops for X86_PATCH Leon Hwang
2023-12-05 13:08 ` Maciej Fijalkowski [this message]
2023-10-11 15:27 ` [RFC PATCH bpf-next v2 2/4] bpf, x64: Fix tailcall hierarchy Leon Hwang
2023-12-05 23:03 ` Maciej Fijalkowski
2023-12-06 6:51 ` Leon Hwang
2023-12-11 18:02 ` Maciej Fijalkowski
2023-12-13 2:48 ` Leon Hwang
2023-12-21 12:02 ` Maciej Fijalkowski
2023-12-21 14:56 ` Leon Hwang
2024-01-04 6:23 ` Alexei Starovoitov
2023-10-11 15:27 ` [RFC PATCH bpf-next v2 3/4] bpf, x64: Load tail_call_cnt pointer Leon Hwang
2023-12-11 18:03 ` Maciej Fijalkowski
2023-12-13 2:49 ` Leon Hwang
2023-10-11 15:27 ` [RFC PATCH bpf-next v2 4/4] selftests/bpf: Add testcases for tailcall hierarchy fixing Leon Hwang
2023-12-11 18:05 ` Maciej Fijalkowski
2023-12-13 3:09 ` Leon Hwang
2023-11-16 8:33 ` [RFC PATCH bpf-next v2 0/4] bpf, x64: Fix tailcall hierarchy Leon Hwang
2023-11-17 21:40 ` Alexei Starovoitov
2023-11-20 12:41 ` Maciej Fijalkowski
2023-12-05 3:09 ` Alexei Starovoitov
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=ZW8gsbqkJwC1x4Cs@boxer \
--to=maciej.fijalkowski@intel.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=hengqi.chen@gmail.com \
--cc=hffilwlqm@gmail.com \
--cc=iii@linux.ibm.com \
--cc=jakub@cloudflare.com \
/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