From: "Petr Mládek" <pmladek@suse.cz>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@elte.hu>,
Frederic Weisbecker <fweisbec@gmail.com>,
Jiri Kosina <jkosina@suse.cz>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] ring-buffer: Race when writing and swapping cpu buffer in parallel
Date: Mon, 21 Jul 2014 18:18:28 +0200 [thread overview]
Message-ID: <20140721161828.GH20751@pathway.suse.cz> (raw)
In-Reply-To: <20140721154317.GS8690@linux.vnet.ibm.com>
On Mon 2014-07-21 08:43:17, Paul E. McKenney wrote:
> On Mon, Jul 21, 2014 at 04:43:24PM +0200, Petr Mládek wrote:
>
> IIRC, deadlock in the case where two CPUs attempt to invoke
> smp_call_function_single() at each other, but both have
> interrupts disabled. It might be possible to avoid this by telling
> smp_call_function_single() not to wait for a response, but this often
> just re-introduces the deadlock at a higher level.
I thought that IPI used NMI and thus could not be blocked if the
called function was reasonable. Note that ring_buffer_swap_cpu() does not take
any lock and can't block anywhere. I am probably too optimistic here.
> > Any pointers or ideas are welcome.
>
> Not immediately. Mark Batty (mark.batty@cl.cam.ac.uk) has come up with
> cute ring-buffer tricks in the past, but would need a clear statement of
> the problem. I would be happy to bring him into the discussion if it
> would help.
In short. We have two operations: writing and swap. They "block" each
other by setting the variables "committing" and "record_disabled".
It is not a real block. The other operation is "nop" when the other
one is in the critical section.
We want to keep writing fast and avoid memory barriers there. Writing
works with per-CPU buffer. It would help when also the swap happens
on the same CPU.
More detailed description of the current race can be found at
https://lkml.org/lkml/2014/7/16/178
> And yes, my knee-jerk reaction of suggesting RCU runs into the problem
> that it is not so good to invoke synchronize_rcu() with interrupts
> disabled. Might be able to use call_rcu(), but if that worked, then
> just telling smp_call_function_single() not to wait would probably
> be a lot simpler.
I am still not sure if it really has to be called with IRQs disabled.
BTW: I have just got another idea. If we store pointer to the used
cpu_buffer into struct ring_buffer_event, it might be possible
to keep the write operation consistent even when the cpu buffers
are switched.
Best Regards,
Petr
next prev parent reply other threads:[~2014-07-21 16:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 8:58 [PATCH v3] ring-buffer: Race when writing and swapping cpu buffer in parallel Petr Mladek
2014-07-16 16:43 ` Steven Rostedt
2014-07-18 15:34 ` Petr Mládek
2014-07-21 14:43 ` Petr Mládek
2014-07-21 15:43 ` Paul E. McKenney
2014-07-21 16:18 ` Petr Mládek [this message]
2014-07-21 16:30 ` Steven Rostedt
2014-07-29 9:02 ` Jiri Kosina
2014-07-23 16:28 ` Frederic Weisbecker
2014-07-23 16:34 ` Steven Rostedt
2014-07-23 16:47 ` Frederic Weisbecker
2014-07-23 16:49 ` Petr Mládek
2014-07-23 16:55 ` Steven Rostedt
2014-07-21 16:07 ` Steven Rostedt
2014-07-22 9:41 ` Petr Mládek
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=20140721161828.GH20751@pathway.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