From: sashiko-bot@kernel.org
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 11/18] selftests/bpf: Check liveness merge of masks with different widths
Date: Wed, 23 Sep 2026 19:26:07 +0000 [thread overview]
Message-ID: <20260923192607.8FC661F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260923191139.2816206-12-memxor@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] bpf: merge_keeps_whole_frame_read test is vacuous on some 64-bit archs
--
commit 1299c778ee1ba2ffa8d447fa3ce55a6d2aec24cd
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
selftests/bpf: Check liveness merge of masks with different widths
This commit adds a selftest to verify that merge_instances() correctly
widens liveness masks of different widths when a function instance is
analyzed through different call sites.
> diff --git a/tools/testing/selftests/bpf/progs/verifier_live_stack.c b/tools/testing/selftests/bpf/progs/verifier_live_stack.c
> index f8758eb62dac5..a94365decd5f1 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_live_stack.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_live_stack.c
> @@ -2861,3 +2861,52 @@ __naked void narrow_store_defines_nothing(void)
[ ... ]
> +SEC("socket")
> +__log_level(2)
> +__msg("stack use/def subprog#{{[0-9]+}} merge_read_all_callee (d2,cs{{[0-9]+}}):")
> +__msg("(79) r0 = *(u64 *)(r1 +0){{.*}}; use: fp0-8..-512")
> +__naked void merge_keeps_whole_frame_read(void)
> +{
> + asm volatile (
> + "r1 = 0;"
> + "*(u64 *)(r10 - 8) = r1;"
> + "*(u64 *)(r10 - 16) = r1;"
> + "*(u64 *)(r10 - 264) = r1;"
[Severity: Low]
Is this test effectively vacuous on 64-bit architectures with a 512-byte stack
limit?
The precise 8-byte read at offset -264 touches half-slot 66. This means the
mask requires 66 bits, which on a 64-bit architecture occupies 2 words.
The second pass performs an unknown-offset read, forcing a whole-frame mask.
For a 512-byte stack limit, this covers 128 half-slots (128 bits), which
also occupies 2 words.
Because both masks occupy 2 words, the actual widening logic in
widen_frame_masks() is silently skipped, missing the intended test coverage.
While later patches in this series might raise the stack limit for some
architectures, the test remains mathematically vacuous on 64-bit architectures
that retain the 512-byte limit (e.g., RISC-V, s390x, or when JIT is off).
Would changing the precise read to an offset <= 256 (e.g., -248) correctly
produce a 1-word mask and test the intended logic universally?
> + "call %[bpf_get_prandom_u32];"
> + "r0 &= 8;"
> + "r1 = r10;"
> + "r1 += -16;"
> + "r1 += r0;"
> + "call merge_read_all_mid;"
> + "r1 = r10;"
> + "r1 += -264;"
> + "call merge_read_all_mid;"
> + "r0 = 0;"
> + "exit;"
> + :: __imm(bpf_get_prandom_u32)
> + : __clobber_all);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260923191139.2816206-1-memxor@gmail.com?part=11
next prev parent reply other threads:[~2026-09-23 19:26 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 19:11 [PATCH bpf-next v1 00/18] Raise BPF program stack size to 2KiB Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 01/18] bpf: Add accessors for verifier stack slots Kumar Kartikeya Dwivedi
2026-09-23 19:57 ` bot+bpf-ci
2026-09-23 20:04 ` Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 02/18] bpf: Widen the stack slot index in the jump history Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 03/18] bpf: Store linked registers in the jump history as an array Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 04/18] bpf: Track backtracking stack slots with bitmaps Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 05/18] bpf: Track scratched stack slots with a bitmap Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 06/18] bpf: Treat unknown-size stack reads as reaching the frame top Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 07/18] bpf: Size liveness stack masks by the stack each frame uses Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 08/18] bpf: Grow the verifier id scratch on demand Kumar Kartikeya Dwivedi
2026-09-23 19:24 ` sashiko-bot
2026-09-23 19:29 ` Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 09/18] selftests/bpf: Cover the tail call caller stack depth limit Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 10/18] selftests/bpf: Check that narrow stack stores define no slot Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 11/18] selftests/bpf: Check liveness merge of masks with different widths Kumar Kartikeya Dwivedi
2026-09-23 19:26 ` sashiko-bot [this message]
2026-09-23 19:29 ` Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 12/18] bpf: Size the per-frame verifier structures for a 2 KiB stack Kumar Kartikeya Dwivedi
2026-09-23 20:12 ` bot+bpf-ci
2026-09-23 20:27 ` Kumar Kartikeya Dwivedi
2026-09-23 22:55 ` Alexei Starovoitov
2026-09-23 19:11 ` [PATCH bpf-next v1 13/18] bpf: Bound program stack use by a per-program limit Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 14/18] selftests/bpf: Add load conditions on the program stack limit Kumar Kartikeya Dwivedi
2026-09-23 20:12 ` bot+bpf-ci
2026-09-23 20:27 ` Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 15/18] selftests/bpf: Give the 512-byte stack boundary tests a 2 KiB twin Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 16/18] bpf, x86: Allow programs 2 KiB of stack Kumar Kartikeya Dwivedi
2026-09-23 20:12 ` bot+bpf-ci
2026-09-23 20:28 ` Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 17/18] bpf, arm64: " Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 18/18] selftests/bpf: Test the 2 KiB stack budget Kumar Kartikeya Dwivedi
2026-09-23 20:12 ` bot+bpf-ci
2026-09-23 20:28 ` Kumar Kartikeya Dwivedi
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=20260923192607.8FC661F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=memxor@gmail.com \
--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 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.