[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240207104703.071ee985@rorschach.local.home>
Date: Wed, 7 Feb 2024 10:47:03 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Sven Schnelle <svens@...ux.ibm.com>
Cc: Mete Durlu <meted@...ux.ibm.com>, Masami Hiramatsu
<mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH] tracing: use ring_buffer_record_is_set_on() in
tracer_tracing_is_on()
On Wed, 07 Feb 2024 14:33:21 +0100
Sven Schnelle <svens@...ux.ibm.com> wrote:
> My assumption without reading the code is that something like this
> happens:
>
> CPU0 CPU1
> [ringbuffer enabled]
> ring_buffer_write()
> if (atomic_read(&buffer->record_disabled))
> goto out;
> echo 0 > tracing_on
> record_disabled |= RB_BUFFER_OFF
> csum1=`md5sum trace`
Note, the CPU1 is performing with preemption disabled, so for this to
happen, something really bad happened on CPU0 to delay preempt disabled
section so long to allow the trace to be read. Perhaps we should have
the return of the echo 0 > tracing_on require a synchronize_rcu() to
make sure all ring buffers see it disabled before it returns.
But unless your system is doing something really stressed to cause the
preempt disabled section to take so long, I highly doubt this was the
race.
-- Steve
> [adds trace entry to ring buffer,
> overwriting savedcmd_lines entry because
> it thinks ring buffer is enabled]
> csum2=`md5sum trace`
Powered by blists - more mailing lists