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 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.