From: Pengfei Li <[email protected]> On Fri, 21 Aug 2026 23:51:29 -0400 Steven Rostedt wrote: > 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?
Nothing that hurts the kernel. The map side stands on its own: the resetting flag turns away new get_id() callers, synchronize_rcu() drains the in-flight ones, and reset frees nothing - it only memsets storage it still owns. So there is no use-after-free and no torn read to worry about. What is left is purely what userspace reads back. The buffer can still hold TRACE_STACK_ID events after the map has been cleared, and those ids resolve in one of two ways: either stack_map has no entry for the id, or - once tracing continues and the slot gets reused - the id now resolves to an unrelated stack. The second one is the uglier of the two, since it is silent misattribution rather than an obvious gap. Either way it is misleading output, not corruption. Since that is the whole exposure, I agree it does not warrant machinery to close the traceon window. v5 documents reset as best-effort and leaves it at that. If you would rather relax it further - drop the -EBUSY when tracing is on, and stop clearing the ring buffer, leaving reset to only clear the map - I am happy to do that. I would send it as a follow-up rather than hold v5 on it, since the id-reuse case above is the only thing the buffer clear was buying and it is cosmetic. Thanks, Pengfei
