bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@meta.com>
To: menglong8.dong@gmail.com, alexei.starovoitov@gmail.com
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	martin.lau@linux.dev, song@kernel.org, yhs@fb.com,
	john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com,
	haoluo@google.com, jolsa@kernel.org, benbjiang@tencent.com,
	bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
	Menglong Dong <imagedong@tencent.com>
Subject: Re: [PATCH bpf-next v5 1/3] bpf, x86: clean garbage values when store args from regs into stack
Date: Sun, 18 Jun 2023 15:52:11 -0700	[thread overview]
Message-ID: <12ff965a-12d7-e7f4-a577-5e645d4ff6c0@meta.com> (raw)
In-Reply-To: <20230613025226.3167956-2-imagedong@tencent.com>



On 6/12/23 7:52 PM, menglong8.dong@gmail.com wrote:
> From: Menglong Dong <imagedong@tencent.com>
> 
> There are garbage values in upper bytes when we store the arguments
> into stack in save_regs() if the size of the argument less then 8.
> 
> As we already reserve 8 byte for the arguments in regs and stack,
> it is ok to store/restore the regs in BPF_DW size. Then, the garbage
> values in upper bytes will be cleaned.

Please make it clear that there are no bugs in the existing code
since for each argument, a type case will happen like
     (parameter_type)ctx[stack_slot]
where ctx[] is an u64 type array. The compiler will generate
correct code to do type casting so garbage value will not impact
the final result. But indeed, uniformly
do save/restore with BPF_DW size can simplify code.

> 
> Signed-off-by: Menglong Dong <imagedong@tencent.com>

Acked-by: Yonghong Song <yhs@fb.com>

> ---
>   arch/x86/net/bpf_jit_comp.c | 35 ++++++-----------------------------
>   1 file changed, 6 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index 1056bbf55b17..a407fbbffecd 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -1860,57 +1860,34 @@ st:			if (is_imm8(insn->off))
>   static void save_regs(const struct btf_func_model *m, u8 **prog, int nr_regs,
>   		      int stack_size)
>   {
> -	int i, j, arg_size;
> -	bool next_same_struct = false;
> +	int i;
>   
>   	/* Store function arguments to stack.
>   	 * For a function that accepts two pointers the sequence will be:
>   	 * mov QWORD PTR [rbp-0x10],rdi
>   	 * mov QWORD PTR [rbp-0x8],rsi
>   	 */
> -	for (i = 0, j = 0; i < min(nr_regs, 6); i++) {
> -		/* The arg_size is at most 16 bytes, enforced by the verifier. */
> -		arg_size = m->arg_size[j];
> -		if (arg_size > 8) {
> -			arg_size = 8;
> -			next_same_struct = !next_same_struct;
> -		}
> -
> -		emit_stx(prog, bytes_to_bpf_size(arg_size),
> -			 BPF_REG_FP,
> +	for (i = 0; i < min(nr_regs, 6); i++)
> +		emit_stx(prog, BPF_DW, BPF_REG_FP,
>   			 i == 5 ? X86_REG_R9 : BPF_REG_1 + i,
>   			 -(stack_size - i * 8));
> -
> -		j = next_same_struct ? j : j + 1;
> -	}
>   }
>   
[...]

  reply	other threads:[~2023-06-18 22:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-13  2:52 [PATCH bpf-next v5 0/3] bpf, x86: allow function arguments up to 12 for TRACING menglong8.dong
2023-06-13  2:52 ` [PATCH bpf-next v5 1/3] bpf, x86: clean garbage values when store args from regs into stack menglong8.dong
2023-06-18 22:52   ` Yonghong Song [this message]
2023-06-19  2:17     ` Menglong Dong
2023-06-13  2:52 ` [PATCH bpf-next v5 2/3] bpf, x86: allow function arguments up to 12 for TRACING menglong8.dong
2023-06-15  4:00   ` Menglong Dong
2023-06-18 23:10   ` Yonghong Song
2023-06-19  2:31     ` Menglong Dong
2023-06-22  9:06     ` David Laight
2023-06-22 13:05       ` Menglong Dong
2023-06-22 14:18         ` David Laight
2023-06-23 13:08           ` Menglong Dong
2023-06-22 16:26       ` Yonghong Song
2023-06-13  2:52 ` [PATCH bpf-next v5 3/3] selftests/bpf: add testcase for TRACING with 6+ arguments menglong8.dong

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=12ff965a-12d7-e7f4-a577-5e645d4ff6c0@meta.com \
    --to=yhs@meta.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=benbjiang@tencent.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=imagedong@tencent.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=sdf@google.com \
    --cc=song@kernel.org \
    --cc=yhs@fb.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;
as well as URLs for NNTP newsgroup(s).