From: Sven Schnelle <svens@linux.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Mete Durlu <meted@linux.ibm.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH] tracing: use ring_buffer_record_is_set_on() in tracer_tracing_is_on()
Date: Wed, 07 Feb 2024 14:33:21 +0100 [thread overview]
Message-ID: <yt9dzfwch00u.fsf@linux.ibm.com> (raw)
In-Reply-To: <20240207072812.4a29235f@rorschach.local.home> (Steven Rostedt's message of "Wed, 7 Feb 2024 07:28:12 -0500")
Steven Rostedt <rostedt@goodmis.org> writes:
> On Wed, 7 Feb 2024 13:07:36 +0100
> Mete Durlu <meted@linux.ibm.com> wrote:
>
>> wouldn't the following scenario explain the behavior we are seeing.
>> When using event triggers, trace uses lockless ringbuffer control paths.
>> If cmdline update and trace output reading is happening on different
>> cpus, the ordering can get messed up.
>>
>> 1. event happens and trace trigger tells ring buffer to stop writes
>> 2. (on cpu#1)test calculates checksum on current state of trace
>> output.
>> 3. (on cpu#2)not knowing about the trace buffers status yet, writer adds
>> a one last entry which would collide with a pid in cmdline map before
>> actually stopping. While (on cpu#1) checksum is being calculated, new
>> saved cmdlines entry is waiting for spinlocks to be unlocked and then
>> gets added.
>> 4. test calculates checksum again and finds that the trace output has
>> changed. <...> is put on collided pid.
>
> But the failure is here:
>
> on=`cat tracing_on`
> if [ $on != "0" ]; then
> fail "Tracing is not off"
> fi
It might be misleading because we're discussing two issues in one
thread. The failure above was one problem, which the initial fix
is for. The other issue we're still seeing is the test below:
> csum1=`md5sum trace`
> sleep $SLEEP_TIME
> csum2=`md5sum trace`
>
> if [ "$csum1" != "$csum2" ]; then
> fail "Tracing file is still changing"
> fi
>
> 1. tracing is off
> 2. do checksum of trace
> 3. sleep
> 4. do another checksum of trace
> 5. compare the two checksums
>
> Now how did they come up differently in that amount of time? The
> saved_cmdlines really should not have been updated.
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`
[adds trace entry to ring buffer,
overwriting savedcmd_lines entry because
it thinks ring buffer is enabled]
csum2=`md5sum trace`
next prev parent reply other threads:[~2024-02-07 13:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-05 6:53 [PATCH] tracing: use ring_buffer_record_is_set_on() in tracer_tracing_is_on() Sven Schnelle
2024-02-05 12:55 ` Steven Rostedt
2024-02-05 13:16 ` Sven Schnelle
2024-02-05 14:23 ` Steven Rostedt
2024-02-05 15:09 ` Sven Schnelle
2024-02-06 6:32 ` Sven Schnelle
2024-02-06 8:48 ` Sven Schnelle
2024-02-06 11:01 ` Steven Rostedt
2024-02-07 5:50 ` Sven Schnelle
2024-02-07 11:09 ` Steven Rostedt
2024-02-07 12:07 ` Mete Durlu
2024-02-07 12:28 ` Steven Rostedt
2024-02-07 13:33 ` Sven Schnelle [this message]
2024-02-07 15:47 ` Steven Rostedt
2024-02-08 10:25 ` Mete Durlu
2024-02-12 18:53 ` Steven Rostedt
2024-02-12 22:54 ` Mete Durlu
2024-02-12 23:12 ` Steven Rostedt
2024-02-06 7:05 ` Mete Durlu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yt9dzfwch00u.fsf@linux.ibm.com \
--to=svens@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=meted@linux.ibm.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox