Linux Perf Users
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Aaron Tomlin" <atomlin@atomlin.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH perf-tools-next v11 05/10] perf ftrace: Support context switch tracking in function graph tracer
Date: Sun, 25 Oct 2026 18:29:04 +0000	[thread overview]
Message-ID: <sashiko-outbox-184338@kernel.org> (raw)
In-Reply-To: <20261025181125.514372-6-atomlin@atomlin.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] perf ftrace: broken min_raw_indent tracking in ftrace_task_state__rekey()
- [Medium] perf ftrace: non-contiguous unknown-PID splice in ftrace_task_state__rekey()
--

commit 242f56625a11f73350f70f6bfa60c779b6624a22
Author: Aaron Tomlin <atomlin@atomlin.com>

perf ftrace: Support context switch tracking in function graph tracer

This commit adds context switch banner parsing and per-task call stack state
tracking to the function graph tracer in perf ftrace, including task state
rekeying and stack splicing across CPU migrations.

> diff --git a/tools/perf/util/ftrace.c b/tools/perf/util/ftrace.c
> index 95db57e70d11b..055b5eb6b8327 100644
> --- a/tools/perf/util/ftrace.c
> +++ b/tools/perf/util/ftrace.c
[ ... ]
> @@ -124,6 +129,208 @@ static int ftrace_task_state__grow_stack(struct ftrace_task_state *cs)
>  	return 0;
>  }
>  
> +/**
> + * ftrace_task_state__rekey - Reassign a task state to a new PID
> + * @ts: The task state to re-key
> + * @new_pid: The new process ID to associate with the state
> + *
> + * Rehash @ts under @new_pid. If a task state for @new_pid already exists,
> + * merge or replace it and update active CPU references accordingly.
> + *
> + * Return: A pointer to the active task state associated with @new_pid.
> + */
> +static struct ftrace_task_state *ftrace_task_state__rekey(struct ftrace_task_state *ts,
> +							  pid_t new_pid)
> +{
> +	struct ftrace_task_state *existing;
> +	u32 key;
> +	int j, c;
> +	int to_copy;
> +
> +	if (ts->pid == new_pid)
> +		return ts;
> +
> +	hlist_del_init(&ts->node);
> +
> +	existing = find_task_state(new_pid);
> +	if (existing) {
> +		int split_idx = existing->depth;
> +		int old_split_idx, post_count;
> +		int base_raw_indent, post_raw_indent;
> +
> +		for (c = 0; c < FTRACE_MAX_CPUS; c++) {
> +			if (ftrace_cpu_tasks[c] == ts)
> +				ftrace_cpu_tasks[c] = existing;
> +		}
> +
> +		/*
> +		 * Find the split point in existing where frames postdate ts.
> +		 * Frames 0 .. split_idx - 1 were pushed prior to ts.
> +		 * Frames split_idx .. existing->depth - 1 were pushed after ts.
> +		 */
> +		for (j = 0; j < existing->depth; j++) {
> +			if (existing->stack[j].seq > ts->seq) {
> +				split_idx = j;
> +				break;
> +			}
> +		}
> +		old_split_idx = split_idx;
> +		post_count = existing->depth - old_split_idx;
> +
> +		/*
> +		 * Prune pre-ts frames on existing that exited before or during ts
> +		 * (i.e. whose raw_indent >= base_raw_indent, along with any
> +		 * synthesized inlined frames).
> +		 */
> +		base_raw_indent = -1;
> +		if (ts->depth > 0)
> +			base_raw_indent = ts->stack[0].raw_indent;
> +		if (ts->min_raw_indent >= 0 &&
> +		    (base_raw_indent < 0 || ts->min_raw_indent < base_raw_indent))
> +			base_raw_indent = ts->min_raw_indent;
> +
> +		if (base_raw_indent >= 0) {
> +			while (split_idx > 0) {
> +				struct ftrace_stack_frame *top =
> +					&existing->stack[split_idx - 1];
> +
> +				if (top->inlined) {
> +					free(top->name);
> +					top->name = NULL;
> +					if (existing->inlined_depth > 0)
> +						existing->inlined_depth--;
> +					split_idx--;
> +					existing->depth--;
> +				} else if (top->raw_indent >= base_raw_indent) {
> +					free(top->name);
> +					top->name = NULL;
> +					split_idx--;
> +					existing->depth--;
> +				} else {
> +					break;
> +				}
> +			}
> +		}

[Severity: Medium]
Can this split_idx search and pre-ts pruning loop in
ftrace_task_state__rekey() drop active intermediate frames from
existing->stack when an initial unknown-PID state accumulates events both
before and after events on existing?

In the kernel's function_graph tracer, verif_pid() only emits a per-CPU
context switch banner when the traced PID on that CPU changes from its
previous traced PID. Consider when task P starts on CPU 0 (tracked under
ts = FTRACE_UNKNOWN_PID(0)), migrates to CPU 1, and then migrates back to
CPU 0 before any other task produces a trace event on CPU 0:

1. On CPU 0, task P pushes outer frames f1 (raw_indent = 2, seq = 1) and
   f2 (raw_indent = 4, seq = 2) onto ts (FTRACE_UNKNOWN_PID(0)).

2. Task P migrates to CPU 1, where a banner "other => P" binds CPU 1 to
   existing (PID P), and pushes intermediate frames f3 (raw_indent = 6,
   seq = 3) and f4 (raw_indent = 8, seq = 4) onto existing->stack.

3. Task P migrates back to CPU 0. Since no other task emitted a trace
   record on CPU 0 in the meantime, no banner is emitted on CPU 0 and
   CPU 0 remains bound to ts. Task P executes another traced event on
   CPU 0 at seq = 5 (for example, a leaf call or inner frame f5 at
   raw_indent = 10), updating ts->seq to 5.

4. Later, another task runs on CPU 0 and emits "0) P => next", triggering
   ftrace_process_fgraph_line() -> parse_context_switch() ->
   ftrace_task_state__rekey(ts, P).

Because ts->seq is now 5 while existing->stack frames f3 and f4 have
seq = 3 and 4, the loop checking existing->stack[j].seq > ts->seq finds no
match and leaves split_idx = existing->depth. That classifies f3 and f4 as
pre-ts frames, and the pruning loop then compares them against
base_raw_indent = ts->stack[0].raw_indent (2 from f1), freeing and dropping
the active intermediate frames f3 and f4.

> +
> +		/*
> +		 * If newer frames or exits exist on existing, prune any frames
> +		 * on ts that exited before them.
> +		 */
> +		post_raw_indent = -1;
> +		if (existing->seq > ts->seq) {
> +			if (post_count > 0)
> +				post_raw_indent = existing->stack[old_split_idx].raw_indent;
> +			if (existing->min_raw_indent >= 0 &&
> +			    (post_raw_indent < 0 || existing->min_raw_indent < post_raw_indent))
> +				post_raw_indent = existing->min_raw_indent;
> +		}
[ ... ]
> @@ -402,6 +725,9 @@ int ftrace_process_fgraph_line(struct perf_ftrace *ftrace, const char *line, FIL
>  	if (is_exit) {
>  		char exit_name[128];
>  
> +		if (cs->min_raw_indent < 0 || leading_spaces < cs->min_raw_indent)
> +			cs->min_raw_indent = leading_spaces;
> +
>  		extract_exit_func_name(func_start, exit_name, sizeof(exit_name));
>  
>  		top_raw_indent = -1;
> @@ -479,7 +805,9 @@ int ftrace_process_fgraph_line(struct perf_ftrace *ftrace, const char *line, FIL
>  			cs->stack[cs->depth].inlined = false;
>  			cs->stack[cs->depth].indent = leading_spaces;
>  			cs->stack[cs->depth].raw_indent = leading_spaces;
> +			cs->stack[cs->depth].seq = cs->seq;
>  			cs->depth++;
> +			cs->min_raw_indent = -1;
>  		}
>  	}

[Severity: Medium]
Does tracking min_raw_indent as a single unsequenced value that is reset to
-1 on function entry cause ftrace_task_state__rekey() to miscompute
post_raw_indent and base_raw_indent across CPU migrations?

There appear to be two ways this can corrupt the tracked call stack when
ftrace_process_fgraph_line() -> parse_context_switch() ->
ftrace_task_state__rekey() merges ts into existing:

1. In ftrace_task_state__rekey(), existing->min_raw_indent is folded into
   post_raw_indent whenever existing->seq > ts->seq, without checking
   whether that minimum exit indentation was actually recorded after
   ts->seq:

   - Suppose task P on CPU 0 (existing) exits a function at
     leading_spaces = 2 (seq = 1), setting existing->min_raw_indent = 2.
   - Task P migrates to CPU 1 (ts = FTRACE_UNKNOWN_PID(1)) and enters
     functions at indentations 2, 4, and 6 (seq = 2..4, so ts->seq = 4).
   - Task P migrates back to CPU 0 (existing) at seq = 5 and executes a
     leaf call at indent 8 or exits only the deepest frame at indent 6.
     Now existing->seq is 5 (> ts->seq), while existing->min_raw_indent is
     still 2 from seq = 1.
   - When CPU 1 later emits its context switch banner and calls
     ftrace_task_state__rekey(ts, P), existing->seq > ts->seq is true and
     post_raw_indent becomes existing->min_raw_indent (2), causing the
     post-ts pruning loop to pop and free the still-active frames on ts at
     indentations 2 and 4.

2. In ftrace_process_fgraph_line(), pushing a new frame onto cs->stack
   unconditionally sets cs->min_raw_indent = -1. If a task on ts (or
   existing after ts) first exits a pre-migration frame at a shallow
   indentation (such as leading_spaces = 2, setting cs->min_raw_indent = 2)
   and then enters a new function at a deeper indentation (such as
   leading_spaces = 4), resetting cs->min_raw_indent = -1 erases the
   shallow exit watermark. When ftrace_task_state__rekey() subsequently
   computes base_raw_indent or post_raw_indent, it only sees indentation 4
   and fails to prune the already-exited frame at indentation 2.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261025181125.514372-1-atomlin@atomlin.com?part=5

  reply	other threads:[~2026-10-25 18:29 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-25 18:11 [PATCH perf-tools-next v11 00/10] perf ftrace: Support inlined functions and display enhancements in function graph tracer Aaron Tomlin
2026-10-25 18:11 ` [PATCH perf-tools-next v11 01/10] perf ftrace: Handle signals, non-blocking reads and pager exits in __cmd_ftrace() Aaron Tomlin
2026-10-25 18:18   ` sashiko-bot
2026-10-25 18:11 ` [PATCH perf-tools-next v11 02/10] perf ftrace: Optimise __cmd_ftrace() stack frame with strbuf streaming Aaron Tomlin
2026-10-25 18:17   ` sashiko-bot
2026-10-25 18:11 ` [PATCH perf-tools-next v11 03/10] perf ftrace: Support filtering return address comments Aaron Tomlin
2026-10-25 18:16   ` sashiko-bot
2026-10-25 18:11 ` [PATCH perf-tools-next v11 04/10] perf ftrace: Add basic task call stack management Aaron Tomlin
2026-10-25 18:17   ` sashiko-bot
2026-10-25 18:11 ` [PATCH perf-tools-next v11 05/10] perf ftrace: Support context switch tracking in function graph tracer Aaron Tomlin
2026-10-25 18:29   ` sashiko-bot [this message]
2026-10-26  2:42     ` Aaron Tomlin
2026-10-25 18:11 ` [PATCH perf-tools-next v11 06/10] perf ftrace: Support display of inlined functions " Aaron Tomlin
2026-10-25 18:25   ` sashiko-bot
2026-10-25 18:11 ` [PATCH perf-tools-next v11 07/10] perf symbol: Introduce vmlinux_path__find() helper Aaron Tomlin
2026-10-25 18:17   ` sashiko-bot
2026-10-25 18:11 ` [PATCH perf-tools-next v11 08/10] perf test: Add test for ftrace inline and task stack tracking Aaron Tomlin
2026-10-25 18:20   ` sashiko-bot
2026-10-25 18:11 ` [PATCH perf-tools-next v11 09/10] perf ftrace: Support omitting execution duration in function graph tracer Aaron Tomlin
2026-10-25 18:17   ` sashiko-bot
2026-10-25 18:11 ` [PATCH perf-tools-next v11 10/10] perf ftrace: Filter extraneous functions " Aaron Tomlin
2026-10-25 18:29   ` sashiko-bot
2026-10-26  2:45     ` Aaron Tomlin

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=sashiko-outbox-184338@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=atomlin@atomlin.com \
    --cc=linux-perf-users@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