From: sashiko-bot@kernel.org
To: "Paul Chaignon" <paul.chaignon@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH RFC bpf-next 3/7] selftests/bpf: Fix reg_bounds to prune on range violations
Date: Thu, 16 Apr 2026 19:08:44 +0000 [thread overview]
Message-ID: <20260416190845.5F970C2BCAF@smtp.kernel.org> (raw)
In-Reply-To: <91b8f1840277989ac65d05a9ad5e683a98d3d6ec.1776344897.git.paul.chaignon@gmail.com>
Sashiko AI review found 1 potential issue(s):
- [Medium] The early return in `reg_state_cond` silently discards updates, incorrectly preventing mathematically impossible branches from being pruned.
--
commit 9c1398626b454db27a318d8fb3f946b257c46b99
Author: Paul Chaignon <paul.chaignon@gmail.com>
selftests/bpf: Fix reg_bounds to prune on range violations
This patch updates the reg_bounds selftest to correctly detect and prune
dead branches by checking for ill-formed ranges. It marks branches as
invalid if their ranges become ill-formed, matching the verifier logic.
> diff --git a/tools/testing/selftests/bpf/prog_tests/reg_bounds.c b/tools/testing/selftests/bpf/prog_tests/reg_bounds.c
> index 71f5240cc5b7e..c0b3a357a0f4c 100644
> --- a/tools/testing/selftests/bpf/prog_tests/reg_bounds.c
> +++ b/tools/testing/selftests/bpf/prog_tests/reg_bounds.c
[ ... ]
> @@ -837,6 +850,8 @@ static void reg_state_cond(enum num_t t, struct reg_state *x, struct reg_state *
> z2 = y->r[t];
>
> range_cond(t, z1, z2, op, &z1, &z2);
> + if (!is_valid_range(t, z1) || !is_valid_range(t, z2))
> + return;
Does this early return prevent the invalid ranges from being written back
to newx and newy?
If range_cond() produces an invalid range, the function returns immediately
and bypasses the write-back of xx and yy at the end of the function:
if (newx)
*newx = xx;
if (newy)
*newy = yy;
This leaves the output registers with their previous valid state.
When sim_case() later checks if the branch is valid:
reg_state_cond(cond_t, tr1, tr2, op, tr1, tr2, "TRUE");
if (is_valid_reg(tr1) && is_valid_reg(tr2))
tr1->valid = tr2->valid = true;
won't it incorrectly evaluate the old valid state and mark the impossible
branch as valid, defeating the pruning logic?
>
> if (newx) {
> snprintf(buf, sizeof(buf), "%s R1", ctx);
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1776344897.git.paul.chaignon@gmail.com?part=3
next prev parent reply other threads:[~2026-04-16 19:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 13:09 [PATCH RFC bpf-next 0/7] bpf: Fix reg_bounds' slow mode and improve verifier refinement Paul Chaignon
2026-04-16 13:11 ` [PATCH RFC bpf-next 1/7] bpf/verifier: Use intersection checks when simulating to detect dead branches Paul Chaignon
2026-04-16 14:03 ` bot+bpf-ci
2026-04-16 18:39 ` sashiko-bot
2026-04-16 13:12 ` [PATCH RFC bpf-next 2/7] selftests/bpf: Test for empty intersection of tnum and u64 Paul Chaignon
2026-04-16 14:03 ` bot+bpf-ci
2026-04-16 18:53 ` sashiko-bot
2026-04-16 13:12 ` [PATCH RFC bpf-next 3/7] selftests/bpf: Fix reg_bounds to prune on range violations Paul Chaignon
2026-04-16 19:08 ` sashiko-bot [this message]
2026-04-16 13:12 ` [PATCH RFC bpf-next 4/7] bpf: Improve 64bits bounds refinement from u32 bounds Paul Chaignon
2026-04-16 19:33 ` sashiko-bot
2026-04-16 13:12 ` [PATCH RFC bpf-next 5/7] bpf: Remove dead code from u32->*64 refinement logic Paul Chaignon
2026-04-16 13:13 ` [PATCH RFC bpf-next 6/7] selftests/bpf: Hardcode insteresting 32->64 refinement cases Paul Chaignon
2026-04-16 13:13 ` [PATCH RFC bpf-next 7/7] selftests/bpf: new cases handled by 32->64 range refinements Paul Chaignon
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=20260416190845.5F970C2BCAF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=paul.chaignon@gmail.com \
--cc=sashiko@lists.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.