From: sashiko-bot@kernel.org
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v7 6/6] selftests/bpf: Test subprogram instruction statistics
Date: Sat, 08 Aug 2026 06:36:50 +0000 [thread overview]
Message-ID: <20260808063650.DDD8F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260808062601.1070988-7-memxor@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The expected verifier logs for `stats_async_schedule`, `stats_async_outer`, and `stats_async_nested_schedule` mandate exactly 7 instructions and `stack 0`. However, because these are standard C functions (lacking `__naked`) that use inline assembly with `__clobber_common` (which clobbers all caller-saved registers `r0-r5`), the compiler must allocate callee-saved registers (e.g., `r6`, `r7`) for their input operands. This forces the emission of prologue and epilogue stack spills, guaranteeing a non-zero stack depth and a higher instruction count. The rigid `__msg` assertions will fail at runtime.
--
--- Patch [6]: [PATCH bpf-next v7 6/6] selftests/bpf: Test subprogram instruction statistics ---
commit af1dc26c02b580a6a5ab3fdfc1f191d5895df8f8
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
selftests/bpf: Test subprogram instruction statistics
Add small verifier programs with deterministic instruction streams to
exercise per-subprogram self and inclusive instruction accounting. Use
assembly for normal call chains and straight-line callback bodies containing
only moves, calls, and returns or exits.
> 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
> index 0000000000000..cbf83ee9f8f2f
> --- /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 = %[timer];"
> + "r2 = %[stats_async_leaf];"
> + "call %[bpf_timer_set_callback];"
> + :
> + : [timer] "r" (value),
> + __imm_ptr(stats_async_leaf),
> + __imm(bpf_timer_set_callback)
> + : __clobber_common
> + );
> + return 0;
> +}
> +
> +SEC("?raw_tp")
> +__success __log_level(4)
> +/*
> + * self: 9 + 7 + 2 = 18
> + * totals: leaf 2, scheduler 7, main root 18
> + */
> +__msg("subprog 0 (stats_async_direct) main insns_self 9 insns_total 18 stack 0")
> +__msg("subprog {{[0-9]+}} (stats_async_schedule) static insns_self 7 "
> + "insns_total 7 stack 0")
[Severity: Medium]
Since stats_async_schedule() is a standard C function (lacking the __naked
attribute) and the inline assembly uses __clobber_common (clobbering r0-r5),
won't the compiler be forced to allocate callee-saved registers (like r6 or r7)
for the input operands?
If the compiler emits prologue and epilogue stack spills for these registers,
it would result in a non-zero stack depth and a higher instruction count,
causing the expected "stack 0" and "insns_self 7" verifier log assertions to
fail at runtime.
[ ... ]
> +__noinline __used
> +static int stats_async_outer(void *map, __u32 *key, struct bpf_timer *timer)
> +{
> + asm volatile (
> + "r1 = %[timer];"
> + "r2 = %[stats_async_nested_leaf];"
> + "call %[bpf_timer_set_callback];"
> + :
> + : [timer] "r" (timer),
> + __imm_ptr(stats_async_nested_leaf),
> + __imm(bpf_timer_set_callback)
> + : __clobber_common
> + );
> + return 0;
> +}
> +
> +__noinline __used
> +static __u64 stats_async_nested_schedule(struct bpf_map *map, __u32 *key,
> + struct timer_value *value, void *ctx)
> +{
> + asm volatile (
> + "r1 = %[timer];"
> + "r2 = %[stats_async_outer];"
> + "call %[bpf_timer_set_callback];"
> + :
> + : [timer] "r" (value),
> + __imm_ptr(stats_async_outer),
> + __imm(bpf_timer_set_callback)
> + : __clobber_common
> + );
> + return 0;
> +}
> +
> +SEC("?raw_tp")
> +__success __log_level(4)
> +/*
> + * self: 9 + 7 + 7 + 2 = 25
> + * totals: leaf 2, outer 7, scheduler 7, main root 25
> + */
> +__msg("subprog 0 (stats_async_nested) main insns_self 9 insns_total 25 stack 0")
> +__msg("subprog {{[0-9]+}} (stats_async_nested_schedule) static insns_self 7 "
> + "insns_total 7 stack 0")
> +__msg("subprog {{[0-9]+}} (stats_async_outer) static insns_self 7 "
> + "insns_total 7 stack 0")
[Severity: Medium]
Will these assertions fail for the same reason?
Like stats_async_schedule(), both stats_async_outer() and
stats_async_nested_schedule() lack __naked and use __clobber_common, which
will likely cause compiler-emitted stack spills and exceed the expected
"stack 0" and "insns_self 7" values.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260808062601.1070988-1-memxor@gmail.com?part=6
next prev parent reply other threads:[~2026-08-08 6:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-08 6:25 [PATCH bpf-next v7 0/6] Improve stack depth verification stats output Kumar Kartikeya Dwivedi
2026-08-08 6:25 ` [PATCH bpf-next v7 1/6] bpf: Track verifier instruction stats for each subprogram Kumar Kartikeya Dwivedi
2026-08-11 19:35 ` Eduard Zingerman
2026-08-08 6:25 ` [PATCH bpf-next v7 2/6] bpf: Attribute async callback instructions to verification roots Kumar Kartikeya Dwivedi
2026-08-08 7:40 ` bot+bpf-ci
2026-08-11 20:01 ` Eduard Zingerman
2026-08-08 6:25 ` [PATCH bpf-next v7 3/6] bpf: Show more useful info in stack depth stats Kumar Kartikeya Dwivedi
2026-08-08 6:45 ` sashiko-bot
2026-08-11 20:04 ` Eduard Zingerman
2026-08-08 6:25 ` [PATCH bpf-next v7 4/6] selftests/bpf: Adjust veristat stack depth parsing Kumar Kartikeya Dwivedi
2026-08-11 20:50 ` Eduard Zingerman
2026-08-08 6:25 ` [PATCH bpf-next v7 5/6] selftests/bpf: Test stack depth stats without BTF subprog names Kumar Kartikeya Dwivedi
2026-08-11 21:18 ` Eduard Zingerman
2026-08-08 6:25 ` [PATCH bpf-next v7 6/6] selftests/bpf: Test subprogram instruction statistics Kumar Kartikeya Dwivedi
2026-08-08 6:36 ` sashiko-bot [this message]
2026-08-11 21:37 ` Eduard Zingerman
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=20260808063650.DDD8F1F000E9@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.