BPF List
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kernel Team <kernel-team@fb.com>,
	Martin KaFai Lau <martin.lau@kernel.org>,
	Zac Ecob <zacecob@protonmail.com>
Subject: Re: [PATCH bpf-next v3 1/2] bpf: Fix a sdiv overflow issue
Date: Fri, 13 Sep 2024 13:00:10 -0700	[thread overview]
Message-ID: <d162c454-702c-40bd-b1dd-a70fe476e1d7@linux.dev> (raw)
In-Reply-To: <CAADnVQ+RgqfSTOoWVVokk5zXkeUE1ZxF_neH=HMyKwEeFAJ_aA@mail.gmail.com>


On 9/13/24 12:44 PM, Alexei Starovoitov wrote:
> On Fri, Sep 13, 2024 at 8:03 AM Yonghong Song <yonghong.song@linux.dev> wrote:
>> +                               BPF_RAW_INSN((is64 ? BPF_ALU64 : BPF_ALU) |
>> +                                            BPF_OP(BPF_ADD) | BPF_K, BPF_REG_AX,
>> +                                            0, 0, 1),
>> +                               BPF_RAW_INSN((is64 ? BPF_JMP : BPF_JMP32) |
>> +                                            BPF_JGT | BPF_K, BPF_REG_AX,
>> +                                            0, 4, 1),
>> +                               BPF_RAW_INSN((is64 ? BPF_JMP : BPF_JMP32) |
>> +                                            BPF_JEQ | BPF_K, BPF_REG_AX,
>> +                                            0, 1, 0),
>> +                               BPF_RAW_INSN((is64 ? BPF_ALU64 : BPF_ALU) |
>> +                                            BPF_OP(BPF_MOV) | BPF_K, insn->dst_reg,
>> +                                            0, 0, 0),
>> +                               /* BPF_NEG(LLONG_MIN) == -LLONG_MIN == LLONG_MIN */
>> +                               BPF_RAW_INSN((is64 ? BPF_ALU64 : BPF_ALU) |
>> +                                            BPF_OP(BPF_NEG) | BPF_K, insn->dst_reg,
> lgtm, but all of BPF_OP(..) are confusing.
> What's the point?
> We use BPF_OP(insn->code) to reuse the code when we create a new opcode,
> but BPF_OP(BPF_NEG) == BPF_NEG and BPF_OP(BPF_MOV) == BPF_MOV, so why?

Sorry, I focused on the algorithm and missed this one. Yes, changing
BPF_OP(BPF_NEG) to BPF_NEG and other similar cases are correct.

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 69b8d91f5136..068f763dcefb 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -20510,7 +20510,7 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
                         struct bpf_insn *patchlet;
                         struct bpf_insn chk_and_sdiv[] = {
                                 BPF_RAW_INSN((is64 ? BPF_ALU64 : BPF_ALU) |
-                                            BPF_OP(BPF_NEG) | BPF_K, insn->dst_reg,
+                                            BPF_NEG | BPF_K, insn->dst_reg,
                                              0, 0, 0),
                         };
                         struct bpf_insn chk_and_smod[] = {
@@ -20565,7 +20565,7 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
                                  */
                                 BPF_MOV64_REG(BPF_REG_AX, insn->src_reg),
                                 BPF_RAW_INSN((is64 ? BPF_ALU64 : BPF_ALU) |
-                                            BPF_OP(BPF_ADD) | BPF_K, BPF_REG_AX,
+                                            BPF_ADD | BPF_K, BPF_REG_AX,
                                              0, 0, 1),
                                 BPF_RAW_INSN((is64 ? BPF_JMP : BPF_JMP32) |
                                              BPF_JGT | BPF_K, BPF_REG_AX,
@@ -20574,11 +20574,11 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
                                              BPF_JEQ | BPF_K, BPF_REG_AX,
                                              0, 1, 0),
                                 BPF_RAW_INSN((is64 ? BPF_ALU64 : BPF_ALU) |
-                                            BPF_OP(BPF_MOV) | BPF_K, insn->dst_reg,
+                                            BPF_MOV | BPF_K, insn->dst_reg,
                                              0, 0, 0),
                                 /* BPF_NEG(LLONG_MIN) == -LLONG_MIN == LLONG_MIN */
                                 BPF_RAW_INSN((is64 ? BPF_ALU64 : BPF_ALU) |
-                                            BPF_OP(BPF_NEG) | BPF_K, insn->dst_reg,
+                                            BPF_NEG | BPF_K, insn->dst_reg,
                                              0, 0, 0),
                                 BPF_JMP_IMM(BPF_JA, 0, 0, 1),
                                 *insn,
@@ -20588,7 +20588,7 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
                                 /* [R,W]x mod -1 -> 0 */
                                 BPF_MOV64_REG(BPF_REG_AX, insn->src_reg),
                                 BPF_RAW_INSN((is64 ? BPF_ALU64 : BPF_ALU) |
-                                            BPF_OP(BPF_ADD) | BPF_K, BPF_REG_AX,
+                                            BPF_ADD | BPF_K, BPF_REG_AX,
                                              0, 0, 1),
                                 BPF_RAW_INSN((is64 ? BPF_JMP : BPF_JMP32) |

>
> If I'm not missing anything I can remove these BPF_OP wrapping when applying.
> wdyt?

Yes, pelase do. Thanks!


  reply	other threads:[~2024-09-13 20:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-13 15:03 [PATCH bpf-next v3 1/2] bpf: Fix a sdiv overflow issue Yonghong Song
2024-09-13 15:03 ` [PATCH bpf-next v3 2/2] selftests/bpf: Add tests for sdiv/smod overflow cases Yonghong Song
2024-09-13 17:26 ` [PATCH bpf-next v3 1/2] bpf: Fix a sdiv overflow issue Andrii Nakryiko
2024-09-13 19:44 ` Alexei Starovoitov
2024-09-13 20:00   ` Yonghong Song [this message]
2024-09-13 20:20 ` 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=d162c454-702c-40bd-b1dd-a70fe476e1d7@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=martin.lau@kernel.org \
    --cc=zacecob@protonmail.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