From: Puranjay Mohan <puranjay@kernel.org>
To: bpf@vger.kernel.org
Cc: Puranjay Mohan <puranjay@kernel.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Martin KaFai Lau" <martin.lau@linux.dev>,
"Eduard Zingerman" <eddyz87@gmail.com>,
"Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
"Song Liu" <song@kernel.org>,
"Yonghong Song" <yonghong.song@linux.dev>
Subject: [PATCH bpf-next v5 2/6] bpf: Inline bpf_iter_num_new() kfunc
Date: Tue, 4 Aug 2026 06:45:54 -0700 [thread overview]
Message-ID: <20260804134601.2305303-3-puranjay@kernel.org> (raw)
In-Reply-To: <20260804134601.2305303-1-puranjay@kernel.org>
bpf_for() expands to the bpf_iter_num_{new,next,destroy}() kfuncs, which
the verifier emits as regular calls. They are tiny and only touch the
8-byte on-stack iterator state, so open-code them in bpf_fixup_kfunc_call()
like the other special kfuncs there.
Start with bpf_iter_num_new(): R1 points to the iterator, R2/R3 hold
start/end. The inlined sequence mirrors the kfunc and returns the same
-EINVAL / -E2BIG / 0.
start > end is rejected first, so end - start fits in a u32; range-check
it as u32 on both sides ((u32)(end - start) in the kfunc). A movsx-based
check would emit a cpuv4 instruction that some JITs (x86-32, mips32,
sparc64) decode as a plain move and get wrong.
The emitted instructions are plain BPF, so the interpreter path stays
correct and no jit_required marking is needed.
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
kernel/bpf/bpf_iter.c | 4 ++--
kernel/bpf/verifier.c | 24 ++++++++++++++++++++++++
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/bpf_iter.c b/kernel/bpf/bpf_iter.c
index b235e117e206a..d19f1b2861d22 100644
--- a/kernel/bpf/bpf_iter.c
+++ b/kernel/bpf/bpf_iter.c
@@ -782,8 +782,8 @@ __bpf_kfunc int bpf_iter_num_new(struct bpf_iter_num *it, int start, int end)
return -EINVAL;
}
- /* avoid overflows, e.g., if start == INT_MIN and end == INT_MAX */
- if ((s64)end - (s64)start > BPF_MAX_LOOPS) {
+ /* start <= end here, so end - start fits in a u32 without overflow */
+ if ((u32)(end - start) > BPF_MAX_LOOPS) {
s->cur = s->end = 0;
return -E2BIG;
}
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 7439afdc851a7..e0c91f6412228 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -20006,6 +20006,30 @@ int bpf_fixup_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
insn_buf[4] = BPF_ALU64_REG(BPF_SUB, BPF_REG_0, BPF_REG_1);
insn_buf[5] = BPF_ALU64_IMM(BPF_NEG, BPF_REG_0, 0);
*cnt = 6;
+ } else if (desc->func_id == special_kfunc_list[KF_bpf_iter_num_new]) {
+ /* inline bpf_iter_num_new(&it, start, end); R1=&it, R2=start, R3=end */
+ int i = 0;
+
+ /* if (start > end) goto einval; */
+ insn_buf[i++] = BPF_JMP32_REG(BPF_JSGT, BPF_REG_2, BPF_REG_3, 8);
+ /* r0 = (u32)end - (u32)start; if (r0 > BPF_MAX_LOOPS) goto e2big; */
+ insn_buf[i++] = BPF_MOV32_REG(BPF_REG_0, BPF_REG_3);
+ insn_buf[i++] = BPF_ALU32_REG(BPF_SUB, BPF_REG_0, BPF_REG_2);
+ insn_buf[i++] = BPF_JMP_IMM(BPF_JGT, BPF_REG_0, BPF_MAX_LOOPS, 8);
+ /* s->cur = start - 1; s->end = end; return 0; */
+ insn_buf[i++] = BPF_ALU32_IMM(BPF_ADD, BPF_REG_2, -1);
+ insn_buf[i++] = BPF_STX_MEM(BPF_W, BPF_REG_1, BPF_REG_2, 0);
+ insn_buf[i++] = BPF_STX_MEM(BPF_W, BPF_REG_1, BPF_REG_3, 4);
+ insn_buf[i++] = BPF_MOV64_IMM(BPF_REG_0, 0);
+ insn_buf[i++] = BPF_JMP_A(5);
+ /* einval: s->cur = s->end = 0; return -EINVAL; */
+ insn_buf[i++] = BPF_ST_MEM(BPF_DW, BPF_REG_1, 0, 0);
+ insn_buf[i++] = BPF_MOV64_IMM(BPF_REG_0, -EINVAL);
+ insn_buf[i++] = BPF_JMP_A(2);
+ /* e2big: s->cur = s->end = 0; return -E2BIG; */
+ insn_buf[i++] = BPF_ST_MEM(BPF_DW, BPF_REG_1, 0, 0);
+ insn_buf[i++] = BPF_MOV64_IMM(BPF_REG_0, -E2BIG);
+ *cnt = i;
}
if (env->insn_aux_data[insn_idx].arg_prog) {
--
2.53.0-Meta
next prev parent reply other threads:[~2026-08-04 13:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 13:45 [PATCH bpf-next v5 0/6] bpf: Inline the numeric open-coded iterator kfuncs Puranjay Mohan
2026-08-04 13:45 ` [PATCH bpf-next v5 1/6] bpf: Correct the overflow check comment in bpf_iter_num_next() Puranjay Mohan
2026-08-04 14:47 ` bot+bpf-ci
2026-08-04 15:04 ` Puranjay Mohan
2026-08-04 13:45 ` Puranjay Mohan [this message]
2026-08-04 13:45 ` [PATCH bpf-next v5 3/6] bpf: Inline bpf_iter_num_next() kfunc Puranjay Mohan
2026-08-04 13:45 ` [PATCH bpf-next v5 4/6] bpf: Inline bpf_iter_num_destroy() as a no-op Puranjay Mohan
2026-08-04 13:45 ` [PATCH bpf-next v5 5/6] selftests/bpf: Verify inlined numeric iterator shape with __xlated Puranjay Mohan
2026-08-04 13:45 ` [PATCH bpf-next v5 6/6] selftests/bpf: Add bpf_for() benchmark Puranjay Mohan
2026-08-05 17:50 ` [PATCH bpf-next v5 0/6] bpf: Inline the numeric open-coded iterator kfuncs 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=20260804134601.2305303-3-puranjay@kernel.org \
--to=puranjay@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=song@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox