From: Steven Rostedt <rostedt@goodmis.org>
To: Li Pengfei <ljdlns1987@gmail.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Mark Rutland <mark.rutland@arm.com>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
lipengfei28@xiaomi.com, zhangbo56@xiaomi.com
Subject: Re: [RFC PATCH v4 2/3] trace: integrate stackmap into ftrace stack recording path
Date: Tue, 14 Jul 2026 17:53:55 -0400 [thread overview]
Message-ID: <20260714175355.1951b317@gandalf.local.home> (raw)
In-Reply-To: <20260616064119.438063-3-lipengfei28@xiaomi.com>
On Tue, 16 Jun 2026 14:41:18 +0800
Li Pengfei <ljdlns1987@gmail.com> wrote:
> int set_tracer_flag(struct trace_array *tr, u64 mask, int enabled)
> {
> switch (mask) {
> @@ -3993,6 +4091,33 @@ int set_tracer_flag(struct trace_array *tr, u64 mask, int enabled)
> if (!!(tr->trace_flags & mask) == !!enabled)
> return 0;
>
> +#ifdef CONFIG_FTRACE_STACKMAP
> + /*
> + * STACKMAP is intentionally global-instance-only: the dedup map,
> + * its tracefs files (stack_map / stack_map_stat / stack_map_bin)
> + * and the lifetime/reset semantics are tied to the global trace
> + * array. options/stackmap is hidden on secondary instances via
> + * TOP_LEVEL_TRACE_FLAGS, but writes still reach set_tracer_flag()
> + * through the aggregate trace_options file. Reject the enable on
> + * a secondary instance so it cannot be silently accepted and then
> + * become a no-op in the hot path (where tr->stackmap is NULL and
> + * the code falls back to a full stack trace).
> + *
> + * On the global instance, allow the enable while init is still
> + * pending (boot-time trace_options=stackmap is applied before the
> + * tracefs init work creates the map; the hot path falls back
> + * until the map is published). Only reject once init has
> + * permanently failed, so options/stackmap never reports an
> + * enabled no-op. READ_ONCE() suffices: this only inspects the
> + * init state, it does not dereference the map (the hot path uses
> + * smp_load_acquire(&tr->stackmap) for that).
> + */
> + if (mask == TRACE_ITER(STACKMAP) && enabled &&
> + (tr != &global_trace ||
> + READ_ONCE(stackmap_init_state) == STACKMAP_INIT_FAILED))
> + return -EINVAL;
> +#endif
> +
> /* Give the tracer a chance to approve the change */
> if (tr->current_trace->flag_changed)
> if (tr->current_trace->flag_changed(tr, mask, !!enabled))
> @@ -9222,6 +9347,91 @@ static __init void tracer_init_tracefs_work_func(struct work_struct *work)
> NULL, &tracing_dyn_info_fops);
> #endif
>
> +#ifdef CONFIG_FTRACE_STACKMAP
> + {
> + struct ftrace_stackmap *smap;
> + struct dentry *map_file;
> +
> + smap = ftrace_stackmap_create(&global_trace);
> + if (!IS_ERR(smap)) {
> + /*
> + * Failure-atomic init: stack_map is the single
> + * required tracefs file (it doubles as the reset
> + * interface and the human-readable resolver). If
> + * we cannot create it, the hot path must not be
> + * able to emit <stack_id N> events that no one can
> + * resolve or clear, so refuse to publish the map
> + * and tear it down.
> + *
> + * Create stack_map BEFORE smp_store_release() so an
> + * observed non-NULL global_trace.stackmap implies
> + * its resolver/reset file exists.
> + */
> + map_file = trace_create_file("stack_map",
> + TRACE_MODE_WRITE, NULL,
> + smap,
> + &ftrace_stackmap_fops);
> + if (!map_file) {
> + pr_warn("ftrace stackmap init: stack_map create failed, dedup disabled\n");
> + ftrace_stackmap_destroy(smap);
> + /*
> + * Permanent failure. Record it and clear a
> + * STACKMAP flag that a boot-time
> + * trace_options=stackmap may have set, so
> + * options/stackmap does not report an
> + * enabled no-op and later userspace enables
> + * return -EINVAL.
> + */
> + WRITE_ONCE(stackmap_init_state,
> + STACKMAP_INIT_FAILED);
> + global_trace.trace_flags &=
> + ~TRACE_ITER(STACKMAP);
80 columns is no longer a hard requirement. 100 is more the default, so the
above should be:
WRITE_ONCE(stackmap_init_state, STACKMAP_INIT_FAILED);
global_trace.trace_flags &= ~TRACE_ITER(STACKMAP);
> + } else {
> + /*
> + * smp_store_release pairs with the
> + * smp_load_acquire() in
> + * __ftrace_trace_stack(). Publishing only
> + * after the required file exists keeps
> + * "smap visible" => "resolver/reset
> + * available".
> + */
> + smp_store_release(&global_trace.stackmap,
> + smap);
> + WRITE_ONCE(stackmap_init_state,
> + STACKMAP_INIT_DONE);
Same with the above two.
> + /*
> + * stat and bin are auxiliary observability
> + * surfaces. If they fail to be created we
> + * keep dedup enabled (the kernel side still
> + * works, and stack_map alone is enough to
> + * resolve and reset); trace_create_file()
> + * already pr_warn()s on failure.
> + */
> + trace_create_file("stack_map_stat",
> + TRACE_MODE_READ, NULL,
> + smap,
> + &ftrace_stackmap_stat_fops);
> + trace_create_file("stack_map_bin",
> + TRACE_MODE_READ, NULL,
> + smap,
> + &ftrace_stackmap_bin_fops);
> + }
-- Steve
next prev parent reply other threads:[~2026-07-14 21:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 6:41 [RFC PATCH v4 0/3] trace: stack trace deduplication for ftrace ring buffer Li Pengfei
2026-06-16 6:41 ` [RFC PATCH v4 1/3] trace: add lock-free stackmap for stack trace deduplication Li Pengfei
2026-07-14 21:11 ` Steven Rostedt
2026-07-15 3:12 ` Li Pengfei
2026-06-16 6:41 ` [RFC PATCH v4 2/3] trace: integrate stackmap into ftrace stack recording path Li Pengfei
2026-07-14 21:53 ` Steven Rostedt [this message]
2026-06-16 6:41 ` [RFC PATCH v4 3/3] trace: add documentation, selftest and tooling for stackmap Li Pengfei
2026-07-06 6:31 ` [RFC PATCH v4 0/3] trace: stack trace deduplication for ftrace ring buffer Li Pengfei
2026-07-10 19:14 ` 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=20260714175355.1951b317@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=lipengfei28@xiaomi.com \
--cc=ljdlns1987@gmail.com \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=zhangbo56@xiaomi.com \
/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