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

On Wed, 15 Jul 2026 11:12:45 +0800
Li Pengfei [off-list ref] 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