From: "Petr Mládek" <pmladek@suse.cz>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Ingo Molnar <mingo@elte.hu>, 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: Wed, 23 Jul 2014 18:49:18 +0200 [thread overview]
Message-ID: <20140723164918.GS20751@pathway.suse.cz> (raw)
In-Reply-To: <20140723123458.314a43fa@gandalf.local.home>
On Wed 2014-07-23 12:34:58, Steven Rostedt wrote:
> On Wed, 23 Jul 2014 18:28:48 +0200
> Frederic Weisbecker <fweisbec@gmail.com> wrote:
>
> > On Mon, Jul 21, 2014 at 08:43:17AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 21, 2014 at 04:43:24PM +0200, Petr Mládek wrote:
> > > > 2. Go back, do the swap on any CPU, and do memory barriers via IPI.
> > > >
> > > > I wonder if the needed memory barrier in rb_reserve_next_event()
> > > > could be avoided by calling IPI from ring_buffer_swap_cpu().
> > > >
> > > > I mean that rb_reserve_next_event() will include the current check
> > > > for swapped ring buffer without barriers. But
> > > > ring_buffer_swap_cpu() will interrupt the affected CPU and
> > > > basically do the barrier there only when needed.
> > > >
> > > > But I am not sure how this is different from calling
> > > > smp_call_function_single() from ring_buffer_swap_cpu().
> > > > And I am back on the question why it is dangerous with disabled
> > > > interrupts. I can't find any clue in git history. And I miss this
> > > > part of the picture :-(
> > >
> > > 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.
> >
> > FWIW, this is what smp_call_function_single_async() does. But then the call
> > must synchronized such that no concurrent call happen until the IPI completion.
> >
> > Otherwise you also have irq_work_queue_on() (not yet upstream but in tip/timers/nohz
> > and tip/sched/core).
>
> Well, the code in question must wait for the IPI to finish, thus as
> Paul said, we just push the issue to the caller.
JFYI, I already have a variant based on https://lkml.org/lkml/2014/7/21/416
It seems to work fine. I just want to double check few things before sending.
Best Regards,
Petr
PS: I am a bit distracted now because my wife is about to give birth
to our twins :-)
next prev parent reply other threads:[~2014-07-23 16:49 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
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 [this message]
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=20140723164918.GS20751@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.