Re: [RFC PATCH v4 1/3] trace: add lock-free stackmap for stack trace deduplication

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 15 Jul 2026 11:12:45 +0800
Li Pengfei <ljdlns1987@gmail.com> wrote:

Sorry for the late reply, I haven't had the time to look deeply at this
series.

> 
> One design point I'd like your steer on before respinning: reset
> checks tracer_tracing_is_on() once under trace_types_lock, but
> traceon triggers (ftrace_traceon / traceon_trigger) can re-enable
> tracing without that lock during reset's clear phase. As far as I
> can tell this is a semantic-contract issue, not a memory-safety
> one: the map is protected by the resetting flag (get_id bails with
> -EINVAL and synchronize_rcu() drains in-flight callers), and the
> ring buffer pages aren't freed by reset, so the worst case is a
> non-empty / inconsistent buffer after reset rather than corruption.
> So I'm leaning toward documenting reset as best-effort ("stop
> tracing, including traceon triggers, before reset") rather than
> adding machinery to block the window. Does that match your view, or
> is there a ring-buffer-state hazard I'm missing that would justify
> blocking it explicitly?

Honestly, I don't think we need to be as strict on reset as you are
trying to be. What is the worse thing that happens if a reset happens
while the buffer is not cleared and the trace still exists?

-- Steve