From: Petr Mladek <pmladek@suse.cz>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@elte.hu>,
Frederic Weisbecker <fweisbec@gmail.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Jiri Kosina <jkosina@suse.cz>,
linux-kernel@vger.kernel.org, Petr Mladek <pmladek@suse.cz>
Subject: [PATCH v4 0/3] ring-buffer/ftrace: Race when writing and swapping cpu buffer in parallel
Date: Tue, 29 Jul 2014 14:31:40 +0200 [thread overview]
Message-ID: <1406637103-15435-1-git-send-email-pmladek@suse.cz> (raw)
OK, I ended with these changes after changing my mind few times and hopefully
better understanding the aspects of preemption, interrupts, locking, and
scheduling.
1st patch fixes the race in ring_buffer_swap_cpu(). It is the one from previous
versions. I have only added checks for irqs_disabled() as suggested by Steven.
2nd patch should be easy. It only makes sure that we are on the same CPU
when handling the critical timings.
3rd patch was the most problematic for me. It creates two variants
of smp_call_function_single() that could be called either with or without
disabled interrupts. It is what Steven suggested but I wonder if it could
be done more elegant way. I am in somewhat strange mode after the twins were
born on Thursday.
Petr Mladek (3):
ring-buffer: Race when writing and swapping cpu buffer in parallel
trace: process entire stop_critical_timing() on the same CPU
trace: Allow to call update_max_tr_single() from another CPU
kernel/trace/ring_buffer.c | 115 ++++++++++++++++++++++++++++++-------------
kernel/trace/trace.c | 60 +++++++++++++++++++---
kernel/trace/trace.h | 1 +
kernel/trace/trace_irqsoff.c | 17 +++++--
4 files changed, 146 insertions(+), 47 deletions(-)
--
1.8.4
next reply other threads:[~2014-07-29 12:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 12:31 Petr Mladek [this message]
2014-07-29 12:31 ` [PATCH v4 1/3] ring-buffer: " Petr Mladek
2014-07-29 12:31 ` [PATCH v4 2/3] trace: process entire stop_critical_timing() on the same CPU Petr Mladek
2014-07-29 12:31 ` [PATCH v4 3/3] trace: Allow to call update_max_tr_single() from another CPU Petr Mladek
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=1406637103-15435-1-git-send-email-pmladek@suse.cz \
--to=pmladek@suse.cz \
--cc=fweisbec@gmail.com \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--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
all inboxes | Powered by JetHome®