From: Vineet Gupta <vineet.gupta@linux.dev>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 10/12] selftests/bpf: Cover the low-32 link for narrowing stack fills
Date: Tue, 20 Oct 2026 10:15:37 -0700 [thread overview]
Message-ID: <9f4fb200-9ec6-42de-8f9f-5eac10f258d7@linux.dev> (raw)
In-Reply-To: <sashiko-outbox-179351@kernel.org>
On 10/20/26 9:29 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] selftests/bpf: misplaced ifdef in sext_byte_fill_drops_sext_link()
> --
>
> commit 0f3b5c981ef84ecf43731c167adb9d7addf744eb
> Author: Vineet Gupta <vineet.gupta@linux.dev>
>
> selftests/bpf: Cover the low-32 link for narrowing stack fills
>
> This commit adds eight BPF verifier selftests covering low-32 scalar link
> tracking across narrowing and sign-extending stack fills, and introduces a
> CAN_USE_LDSX macro in bpf_misc.h to guard tests that use sign-extending
> loads.
>
>> diff --git a/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c b/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c
[snip...]
>> +SEC("socket")
>> +__success __log_level(2)
>> +#ifdef CAN_USE_MOVSX
>> +/*
>> + * Needs MOVSX as well as LDSX: the BPF_REG_LINK_SEXT under test is built with
>> + * r7 = (s32)r6, and only the byte fill below is an ldsx.
>> + */
>> +/* a surviving link would print as R2=scalar(id=N+0.sx,smin=... */
>> +__msg("(91) r2 = *(s8 *)(r10 {{.*}} R2=scalar(smin=")
>> +__naked void sext_byte_fill_drops_sext_link(void)
>> +{
> [ ... ]
>> +}
>> +#endif /* CAN_USE_MOVSX */
>> +
>> +#endif /* CAN_USE_LDSX */
>> +
>> char _license[] SEC("license") = "GPL";
> [Severity: Low]
> Should SEC("socket") and __success __log_level(2) on
> sext_byte_fill_drops_sext_link() be placed inside the #ifdef CAN_USE_MOVSX
> block?
Indeed that bracketing came out weird.
> In tools/testing/selftests/bpf/progs/bpf_misc.h, CAN_USE_LDSX and
> CAN_USE_MOVSX can be enabled independently via __BPF_FEATURE_LDSX and
> __BPF_FEATURE_MOVSX
Independently meaning ? __BPF_FEATURE* are indeed compiler toggle
derived but the CAN_USE* additionally reflect whether arch JITs support
them so they are a combination of __BPF_FEATURE* and arch JIT support.
> (for example, with bpf-gcc -mldsx/-msmov flags).
Just for correctness, -mldsx doesn't exist for gcc, -msmov covers both.
> If CAN_USE_LDSX is defined while CAN_USE_MOVSX is not defined, the body of
> the #ifdef CAN_USE_MOVSX block is preprocessed out, leaving those attributes
> dangling so they attach to the following _license declaration (or to any test
> function added after this block).
Indeed the attribute placement needs fixing.
Thx,
-Vineet
next prev parent reply other threads:[~2026-10-20 17:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 16:18 [PATCH bpf-next v3 00/12] bpf: track scalar equality across the low 32 bits Vineet Gupta
2026-10-20 16:18 ` [PATCH bpf-next v3 01/12] bpf: Keep the 32-bit range across a sign extension that cannot change it Vineet Gupta
2026-10-20 16:18 ` [PATCH bpf-next v3 02/12] selftests/bpf: Cover sign extensions that cannot change the range Vineet Gupta
2026-10-20 16:18 ` [PATCH bpf-next v3 03/12] bpf: Prepare linked scalars for relations narrower than 64 bits Vineet Gupta
2026-10-20 17:08 ` bot+bpf-ci
2026-10-20 16:18 ` [PATCH bpf-next v3 04/12] bpf: Track low-32 scalar equality across zero-extending movs Vineet Gupta
2026-10-20 16:39 ` sashiko-bot
2026-10-20 17:09 ` bot+bpf-ci
2026-10-20 16:19 ` [PATCH bpf-next v3 05/12] selftests/bpf: Cover the low-32 link for " Vineet Gupta
2026-10-20 16:53 ` bot+bpf-ci
2026-10-20 16:19 ` [PATCH bpf-next v3 06/12] bpf: Track low-32 scalar equality across sign-extending movs Vineet Gupta
2026-10-20 16:57 ` sashiko-bot
2026-10-20 16:19 ` [PATCH bpf-next v3 07/12] selftests/bpf: Cover the low-32 link for " Vineet Gupta
2026-10-20 16:19 ` [PATCH bpf-next v3 08/12] bpf: Recover the low 32 bits on the reverse link direction Vineet Gupta
2026-10-20 16:53 ` bot+bpf-ci
2026-10-20 17:20 ` sashiko-bot
2026-10-20 16:19 ` [PATCH bpf-next v3 09/12] bpf: Track low-32 scalar equality across narrowing stack fills Vineet Gupta
2026-10-20 16:19 ` [PATCH bpf-next v3 10/12] selftests/bpf: Cover the low-32 link for " Vineet Gupta
2026-10-20 16:29 ` sashiko-bot
2026-10-20 17:15 ` Vineet Gupta [this message]
2026-10-20 16:52 ` bot+bpf-ci
2026-10-20 16:19 ` [PATCH bpf-next v3 11/12] [do not merge] bpf: Track low-32 scalar equality across narrowing stack spills Vineet Gupta
2026-10-20 16:42 ` sashiko-bot
2026-10-20 16:19 ` [PATCH bpf-next v3 12/12] [do not merge] selftests/bpf: Cover the low-32 link for " Vineet Gupta
2026-10-20 16:32 ` sashiko-bot
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=9f4fb200-9ec6-42de-8f9f-5eac10f258d7@linux.dev \
--to=vineet.gupta@linux.dev \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox