All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.