From: sashiko-bot@kernel.org
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v6 6/6] selftests/bpf: Test subprogram instruction statistics
Date: Wed, 05 Aug 2026 01:23:10 +0000 [thread overview]
Message-ID: <20260805012312.4D4491F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260805011517.1717238-7-memxor@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Inline assembly in non-naked C functions implicitly reads argument registers, risking register corruption and test failures due to unstable instruction counts.
--
--- Patch [6]: [PATCH bpf-next v6 6/6] selftests/bpf: Test subprogram instruction statistics ---
commit 567cc6b8313bad87d8db2a9e9b28df5026767381
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
selftests/bpf: Test subprogram instruction statistics
Adds small verifier programs with deterministic instruction streams to
exercise per-subprogram own and inclusive instruction accounting.
> diff --git a/tools/testing/selftests/bpf/progs/verifier_subprog_insn_stats.c b/tools/testing/selftests/bpf/progs/verifier_subprog_insn_stats.c
> new file mode 100644
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/verifier_subprog_insn_stats.c
[ ... ]
> +__noinline __used
> +static __u64 stats_async_schedule(struct bpf_map *map, __u32 *key,
> + struct timer_value *value, void *ctx)
> +{
> + asm volatile (
> + "r1 = r3;"
[Severity: Medium]
Because stats_async_schedule() is not marked __naked, could the compiler
emit prologue or epilogue instructions that change the exact instruction
count, causing the strict test assertions (e.g., insns_own 6) to fail?
Also, since r3 is implicitly read here without an input constraint, is
there a risk that the register allocator could clobber r3 before the
assembly block executes?
[ ... ]
> +__noinline __used
> +static int stats_async_outer(void *map, __u32 *key, struct bpf_timer *timer)
> +{
> + asm volatile (
> + "r1 = r3;"
[Severity: Medium]
Similarly, does the lack of __naked on stats_async_outer() risk unexpected
prologue instructions breaking the exact instruction counts?
Could the implicit use of r3 without an input constraint result in register
corruption?
[ ... ]
> +__noinline __used
> +static __u64 stats_async_nested_schedule(struct bpf_map *map, __u32 *key,
> + struct timer_value *value, void *ctx)
> +{
> + asm volatile (
> + "r1 = r3;"
[Severity: Medium]
Could the compiler emit extra instructions here for
stats_async_nested_schedule() since it is not marked __naked, breaking
the expected instruction counts?
Does reading r3 without constraints here also risk register corruption?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260805011517.1717238-1-memxor@gmail.com?part=6
prev parent reply other threads:[~2026-08-05 1:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 1:15 [PATCH bpf-next v6 0/6] Improve stack depth verification stats output Kumar Kartikeya Dwivedi
2026-08-05 1:15 ` [PATCH bpf-next v6 1/6] bpf: Track verifier instruction stats for each subprogram Kumar Kartikeya Dwivedi
2026-08-05 1:26 ` sashiko-bot
2026-08-05 1:15 ` [PATCH bpf-next v6 2/6] bpf: Propagate async callback instructions to scheduling subprograms Kumar Kartikeya Dwivedi
2026-08-05 1:40 ` sashiko-bot
2026-08-05 18:18 ` Eduard Zingerman
2026-08-05 1:15 ` [PATCH bpf-next v6 3/6] bpf: Show more useful info in stack depth stats Kumar Kartikeya Dwivedi
2026-08-05 1:28 ` sashiko-bot
2026-08-05 1:15 ` [PATCH bpf-next v6 4/6] selftests/bpf: Adjust veristat stack depth parsing Kumar Kartikeya Dwivedi
2026-08-05 1:15 ` [PATCH bpf-next v6 5/6] selftests/bpf: Test stack depth stats without BTF subprog names Kumar Kartikeya Dwivedi
2026-08-05 1:15 ` [PATCH bpf-next v6 6/6] selftests/bpf: Test subprogram instruction statistics Kumar Kartikeya Dwivedi
2026-08-05 1:23 ` sashiko-bot [this message]
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=20260805012312.4D4491F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox