From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org,
Frederic Weisbecker <fweisbec@gmail.com>,
Mike Galbraith <efault@gmx.de>, Paul Mackerras <paulus@samba.org>,
Stephane Eranian <eranian@google.com>,
Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH] [RFC] perf: Fix a race between ring_buffer_detach() and ring_buffer_wakeup()
Date: Thu, 13 Mar 2014 12:58:16 -0700 [thread overview]
Message-ID: <20140313195816.GJ21124@linux.vnet.ibm.com> (raw)
In-Reply-To: <1394199526-6400-1-git-send-email-alexander.shishkin@linux.intel.com>
On Fri, Mar 07, 2014 at 03:38:46PM +0200, Alexander Shishkin wrote:
> This is more of a problem description than an actual bugfix, but currently
> ring_buffer_detach() can kick in while ring_buffer_wakeup() is traversing
> the ring buffer's event list, leading to cpu stalls.
>
> What this patch does is crude, but fixes the problem, which is: one rcu
> grace period has to elapse between ring_buffer_detach() and subsequent
> ring_buffer_attach(), otherwise either the attach will fail or the wakeup
> will misbehave. Also, making it a call_rcu() callback will make it race
> with attach().
>
> Another solution that I see is to check for list_empty(&event->rb_entry)
> before wake_up_all() in ring_buffer_wakeup() and restart the list
> traversal if it is indeed empty, but that is ugly too as there will be
> extra wakeups on some events.
>
> Anything that I'm missing here? Any better ideas?
Not sure it qualifies as "better", but git call to ring_buffer_detach()
is going to free the event anyway, so the synchronize_rcu() and the
INIT_LIST_HEAD() should not be needed in that case. I am guessing that
the same is true for perf_mmap_close().
So that leaves the call in perf_event_set_output(), which detaches from an
old rb before attaching that same event to a new one. So maybe have the
synchronize_rcu() and INIT_LIST_HEAD() instead be in the "if (old_rb)",
which might be a reasonably uncommon case?
Thanx, Paul
> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
> ---
> kernel/events/core.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 661951a..bce41e0 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -3861,7 +3861,7 @@ static void ring_buffer_attach(struct perf_event *event,
>
> spin_lock_irqsave(&rb->event_lock, flags);
> if (list_empty(&event->rb_entry))
> - list_add(&event->rb_entry, &rb->event_list);
> + list_add_rcu(&event->rb_entry, &rb->event_list);
> spin_unlock_irqrestore(&rb->event_lock, flags);
> }
>
> @@ -3873,9 +3873,11 @@ static void ring_buffer_detach(struct perf_event *event, struct ring_buffer *rb)
> return;
>
> spin_lock_irqsave(&rb->event_lock, flags);
> - list_del_init(&event->rb_entry);
> + list_del_rcu(&event->rb_entry);
> wake_up_all(&event->waitq);
> spin_unlock_irqrestore(&rb->event_lock, flags);
> + synchronize_rcu();
> + INIT_LIST_HEAD(&event->rb_entry);
> }
>
> static void ring_buffer_wakeup(struct perf_event *event)
> --
> 1.9.0
>
next prev parent reply other threads:[~2014-03-13 19:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-07 13:38 [PATCH] [RFC] perf: Fix a race between ring_buffer_detach() and ring_buffer_wakeup() Alexander Shishkin
2014-03-13 19:58 ` Paul E. McKenney [this message]
2014-03-14 9:50 ` Peter Zijlstra
2014-03-14 20:47 ` Paul E. McKenney
2014-03-14 22:43 ` Peter Zijlstra
2014-03-14 23:02 ` Paul E. McKenney
2014-03-15 0:00 ` Paul E. McKenney
2014-03-17 11:18 ` Peter Zijlstra
2014-03-17 16:48 ` Paul E. McKenney
2014-03-17 17:30 ` Peter Zijlstra
2014-03-18 2:45 ` Paul E. McKenney
2014-03-18 8:26 ` Peter Zijlstra
2014-05-07 12:35 ` Peter Zijlstra
2014-05-07 18:06 ` Peter Zijlstra
2014-05-08 15:37 ` Paul E. McKenney
2014-05-08 16:09 ` Peter Zijlstra
2014-05-19 12:48 ` [tip:perf/urgent] perf: Fix a race between ring_buffer_detach() and ring_buffer_attach() tip-bot for Peter Zijlstra
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=20140313195816.GJ21124@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=efault@gmx.de \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulus@samba.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.