From: Peter Zijlstra <peterz@infradead.org>
To: Jiri Olsa <jolsa@kernel.org>
Cc: linux-kernel@vger.kernel.org, Jiri Olsa <jolsa@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Corey Ashford <cjashfor@linux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@kernel.org>, Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH 1/1] perf: Prevent race in PERF_SAMPLE_READ group format sample output
Date: Mon, 7 Jul 2014 11:04:28 +0200 [thread overview]
Message-ID: <20140707090428.GG6758@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1403721875-15669-2-git-send-email-jolsa@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]
On Wed, Jun 25, 2014 at 08:44:35PM +0200, Jiri Olsa wrote:
> From: Jiri Olsa <jolsa@redhat.com>
>
> While iterating siblings in perf_output_read_group we could
> race with addition and removal of sibling in perf_group_attach
> and perf_group_detach respective.
So why would anybody do this?
> While in perf_output_read_group we are under active context,
> so the only sibling_list modification could come via IPI in:
> perf_install_in_context or perf_remove_from_context
>
> Disable interrupts before iterating siblings to prevent
> this race.
>
> Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
> Cc: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
> kernel/events/core.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index a33d9a2b..66649d3 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4509,6 +4509,7 @@ static void perf_output_read_group(struct perf_output_handle *handle,
> {
> struct perf_event *leader = event->group_leader, *sub;
> u64 read_format = event->attr.read_format;
> + unsigned long flags;
> u64 values[5];
> int n = 0;
>
> @@ -4529,6 +4530,15 @@ static void perf_output_read_group(struct perf_output_handle *handle,
>
> __output_copy(handle, values, n * sizeof(u64));
>
> + /*
> + * We are now under active context, so the only sibling_list
> + * modification could come via IPI in:
> + * perf_install_in_context and perf_remove_from_context
> + *
> + * Disable interrupts to prevent this race.
> + */
> + local_irq_save(flags);
I think this is too late; you want it right at the beginning, before we
read ->nr_siblings, as that is also changed by
add_event_to_ctx()->perf_group_attach().
That said; it would be nice not to have to poke at the interrupt flag,
its expensive.
So is this really a problem, or just a case of: if you do silly things,
you get silly results?
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-07-07 9:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-25 18:44 [PATCH 0/1] perf: Fix race in sample output Jiri Olsa
2014-06-25 18:44 ` [PATCH 1/1] perf: Prevent race in PERF_SAMPLE_READ group format " Jiri Olsa
2014-07-02 7:56 ` Jiri Olsa
2014-07-07 9:04 ` Peter Zijlstra [this message]
2014-07-07 10:20 ` Jiri Olsa
2014-07-07 11:43 ` 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=20140707090428.GG6758@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=cjashfor@linux.vnet.ibm.com \
--cc=fweisbec@gmail.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--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.