From: sashiko-bot@kernel.org
To: "Vineet Gupta" <vineet.gupta@linux.dev>
Cc: linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH v3 1/1] tracing: fgraph: allocate shadow stacks inline with GFP_NOWAIT
Date: Thu, 01 Oct 2026 10:37:51 +0000 [thread overview]
Message-ID: <20261001103752.653961F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261001102909.1152572-2-vineet.gupta@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] tracing: mixing goto and scoped_guard in alloc_retstack_tasklist()
--
commit eacae2b1226bb2d8684604b5c37e3ec9f073cb80
Author: Vineet Gupta <vineet.gupta@linux.dev>
tracing: fgraph: allocate shadow stacks inline with GFP_NOWAIT
This commit updates alloc_retstack_tasklist() to allocate return stacks
inline using GFP_NOWAIT within an RCU read-side critical section,
replacing the fixed-batch preallocation loop. It also replaces the
open-coded rcu_read_lock() and rcu_read_unlock() with scoped_guard(rcu)
to handle RCU protection implicitly.
> diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c
> index 40d373d65f9b9..efb5d260334e0 100644
> --- a/kernel/trace/fgraph.c
> +++ b/kernel/trace/fgraph.c
[ ... ]
> @@ -1057,26 +1060,37 @@ static int alloc_retstack_tasklist(unsigned long **ret_stack_list)
> }
> }
>
> - rcu_read_lock();
> - for_each_process_thread(g, t) {
> - if (start == end) {
> - ret = -EAGAIN;
> - goto unlock;
> - }
> + scoped_guard (rcu) {
[Severity: Low]
Does this code mix goto-based error handling and scope-based cleanup in the
same function?
The alloc_retstack_tasklist() function still contains a goto free error
handling path earlier in its body, and a free: cleanup label at the end.
Adding scoped_guard() here violates the kernel cleanup subsystem guidelines,
which state that for a given routine, usage of goto and cleanup helpers
should never be mixed.
Since returning directly from within the scoped_guard() skips the free: loop
at the end of the function, it forces manual reasoning about whether that is
safe. This is noted in the new comment about keeping the start == end check
in step with the exhaustion logic.
Is it possible to convert the initial return stack array allocation to use
scope-based cleanup as well, or revert to open-coded RCU read locks, to
avoid mixing the two patterns?
> + for_each_process_thread(g, t) {
> + unsigned long *rs;
> +
> + if (t->ret_stack)
> + continue;
> +
> + rs = kmem_cache_alloc(fgraph_stack_cachep, GFP_NOWAIT);
> + if (!rs) {
> + /*
> + * Returning from inside scoped_guard() drops
> + * the RCU read lock, but skips the free loop
> + * below. That is only safe because start ==
> + * end here, which leaves that loop nothing to
> + * free. Keep the two in step if this
> + * exhaustion check ever changes.
> + */
> + if (start == end)
> + return -EAGAIN;
> + rs = ret_stack_list[start++];
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261001102909.1152572-2-vineet.gupta@linux.dev?part=1
next prev parent reply other threads:[~2026-10-01 10:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 10:29 [PATCH v3] tracing: fgraph: fix the quadratic shadow stack walk Vineet Gupta
2026-10-01 10:29 ` [PATCH v3 1/1] tracing: fgraph: allocate shadow stacks inline with GFP_NOWAIT Vineet Gupta
2026-10-01 10:37 ` sashiko-bot [this message]
2026-10-01 11:31 ` Masami Hiramatsu
2026-10-01 13:19 ` Andrii Nakryiko
2026-10-11 4:28 ` [PATCH v3] tracing: fgraph: fix the quadratic shadow stack walk Vineet Gupta
2026-10-12 13:42 ` Steven Rostedt
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=20261001103752.653961F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vineet.gupta@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.