[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250527161130.26276a41@gandalf.local.home>
Date: Tue, 27 May 2025 16:11:30 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: LKML <linux-kernel@...r.kernel.org>, Linux Trace Kernel
<linux-trace-kernel@...r.kernel.org>
Cc: Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers
<mathieu.desnoyers@...icios.com>, Vincent Donnefort <vdonnefort@...gle.com>
Subject: Re: [PATCH] ring-buffer: Do not trigger WARN_ON() due to a
commit_overrun
On Tue, 27 May 2025 12:11:40 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:
> But there just happens to be one scenario where this can legitimately
> happen. That is on a commit_overrun. A commit overrun is when an interrupt
> preempts an event being written to the buffer and then the interrupt adds
> so many new events that it fills and wraps the buffer back to the commit.
> Any new events would then be dropped and be reported as "missed_events".
I'll probably update the commit log, but the way I triggered this was to run:
# perf record -o perf-test.dat -a -- trace-cmd record --nosplice -e all -p function hackbench 50
Which causes perf to trigger a bunch of interrupts while trace-cmd enables
function tracing and all events. This is on a debug kernel that has
lockdep, KASAN and interrupt and preemption disabling events enabled.
Basically, this causes a lot to be traced in an interrupt. Enough to fill
1.4 megs of the tracing buffer with events in interrupts before a single
event could be recorded.
I've never triggered this when those extreme conditions were not there.
-- Steve
Powered by blists - more mailing lists