From: Puranjay Mohan <puranjay@kernel.org>
To: Sun Jian <sun.jian.kdev@gmail.com>,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
eddyz87@gmail.com, paul.chaignon@gmail.com, shuah@kernel.org,
linux-kernel@vger.kernel.org, Sun Jian <sun.jian.kdev@gmail.com>
Subject: Re: [PATCH] selftests/bpf: add a 32-bit bounds deduction case
Date: Wed, 18 Mar 2026 12:36:30 +0000 [thread overview]
Message-ID: <m2fr5xnwkx.fsf@kernel.org> (raw)
In-Reply-To: <20260318113200.303824-1-sun.jian.kdev@gmail.com>
Sun Jian <sun.jian.kdev@gmail.com> writes:
> verifier_bounds.c already has 64-bit cross-sign-boundary bounds
> deduction coverage.
>
> Recent 32-bit signed/unsigned intersection tests extended the refinement
> coverage, but a corresponding negative case is still missing.
>
> Add a 32-bit selftest for that case and assert that the program is
> rejected, confirming that verifier remains conservative there.
The "recent 32-bit signed/unsigned intersection tests" are Eduard's
signed_unsigned_intersection32_case1/case2 (commit f81fdfd16771), which
cover the two refinement branches added to deduce_bounds_32_from_32() in
commit fbc7aef517d8.
Your test claims to be a "negative case" for the two-overlap scenario
where the verifier can't refine bounds. But tracing through the code,
that's not what happens. After the two w0 conditionals you have
u32=[0x80, 0xffffff80] and s32=[-128, 127]. In
deduce_bounds_32_from_32():
- (u32)s32_min_value <= (u32)s32_max_value (0xffffff80 <= 0x7f) is false,
so we enter the else branch
- u32_max < (u32)s32_min (0xffffff80 < 0xffffff80) is false, skip
- (u32)s32_max < u32_min (0x7f < 0x80) is true - the single-overlap else
if fires, successfully narrowing the register to the constant 0xffffff80
So this isn't a "two overlaps / no refinement" case at all. The verifier
resolves the value completely. This is the same else if branch that
signed_unsigned_intersection32_case1 already exercises (with u32=[3,
U32_MAX], s32=[S32_MIN, 1], where (u32)1 < 3 fires the same path).
No new coverage is added.
next prev parent reply other threads:[~2026-03-18 12:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 11:32 [PATCH] selftests/bpf: add a 32-bit bounds deduction case Sun Jian
2026-03-18 12:36 ` Puranjay Mohan [this message]
2026-03-19 7:10 ` sun jian
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=m2fr5xnwkx.fsf@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=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=paul.chaignon@gmail.com \
--cc=shuah@kernel.org \
--cc=sun.jian.kdev@gmail.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 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.