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 v4 1/6] bpf: Correct the overflow check comment in bpf_iter_num_next()
Date: Wed, 29 Jul 2026 13:36:21 -0700 [thread overview]
Message-ID: <20260729203633.213973-2-puranjay@kernel.org> (raw)
In-Reply-To: <20260729203633.213973-1-puranjay@kernel.org>
bpf_iter_num_next() decides whether the iterator is exhausted with:
if ((s64)(s->cur + 1) >= s->end) {
The comment above it claimed the (s64) cast was needed to be careful
about overflow, "e.g., if s->cur == s->end == INT_MAX, we can't just do
s->cur + 1 >= s->end". That reasoning is wrong: s->cur + 1 is evaluated
in int and wraps *before* the cast, so casting the already-wrapped result
to s64 changes nothing. For s->cur == s->end == INT_MAX the plain
s->cur + 1 >= s->end and the (s64) version both evaluate to false, and
more generally the two are identical for all inputs (sign-extending both
operands of a signed compare never changes its result).
The wraparound of s->cur + 1 is in fact intentional and load-bearing:
bpf_iter_num_new() initializes s->cur to start - 1, which wraps to
INT_MAX when start == INT_MIN, and the wrapping s->cur + 1 recovers
start on the first call. Using real 64-bit arithmetic ((s64)s->cur + 1)
would instead break iterators starting at INT_MIN.
Drop the redundant cast and rewrite the comment to describe what actually
happens. No functional change; the kernel builds with -fno-strict-overflow
so the signed wraparound is well defined.
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
kernel/bpf/bpf_iter.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/kernel/bpf/bpf_iter.c b/kernel/bpf/bpf_iter.c
index f5eaeb2493d4a..f190f2b250048 100644
--- a/kernel/bpf/bpf_iter.c
+++ b/kernel/bpf/bpf_iter.c
@@ -802,12 +802,14 @@ __bpf_kfunc int *bpf_iter_num_next(struct bpf_iter_num* it)
{
struct bpf_iter_num_kern *s = (void *)it;
- /* check failed initialization or if we are done (same behavior);
- * need to be careful about overflow, so convert to s64 for checks,
- * e.g., if s->cur == s->end == INT_MAX, we can't just do
- * s->cur + 1 >= s->end
+ /* Detect the end of the range, or a failed/empty iterator: all of these
+ * leave s->cur + 1 >= s->end. bpf_iter_num_new() set s->cur to start - 1
+ * (which wraps to INT_MAX when start == INT_MIN), so the s->cur + 1 below
+ * is a deliberate 32-bit wraparound that recovers start. As s->cur and
+ * s->end are int, this is an ordinary signed 32-bit compare, exactly what
+ * the inlined bpf_iter_num_next() emits.
*/
- if ((s64)(s->cur + 1) >= s->end) {
+ if (s->cur + 1 >= s->end) {
s->cur = s->end = 0;
return NULL;
}
--
2.53.0-Meta
next prev parent reply other threads:[~2026-07-29 20:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 20:36 [PATCH bpf-next v4 0/6] bpf: Inline the numeric open-coded iterator kfuncs Puranjay Mohan
2026-07-29 20:36 ` Puranjay Mohan [this message]
2026-07-29 20:49 ` [PATCH bpf-next v4 1/6] bpf: Correct the overflow check comment in bpf_iter_num_next() sashiko-bot
2026-07-29 21:32 ` bot+bpf-ci
2026-07-29 20:36 ` [PATCH bpf-next v4 2/6] bpf: Inline bpf_iter_num_new() kfunc Puranjay Mohan
2026-07-29 20:36 ` [PATCH bpf-next v4 3/6] bpf: Inline bpf_iter_num_next() kfunc Puranjay Mohan
2026-07-29 20:36 ` [PATCH bpf-next v4 4/6] bpf: Inline bpf_iter_num_destroy() as a no-op Puranjay Mohan
2026-07-29 20:36 ` [PATCH bpf-next v4 5/6] selftests/bpf: Verify inlined numeric iterator shape with __xlated Puranjay Mohan
2026-07-29 20:36 ` [PATCH bpf-next v4 6/6] selftests/bpf: Add bpf_for() benchmark Puranjay Mohan
2026-07-29 21:50 ` bot+bpf-ci
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=20260729203633.213973-2-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 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.