From: Mark Rutland <mark.rutland@arm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Yan Zheng <zheng.z.yan@intel.com>,
Stephane Eranian <eranian@google.com>,
Ingo Molnar <mingo@kernel.org>,
Vince Weaver <vincent.weaver@maine.edu>
Subject: Re: Possible race between CPU hotplug and perf_pmu_migrate_context
Date: Fri, 5 Sep 2014 17:59:56 +0100 [thread overview]
Message-ID: <20140905165956.GA28623@leverpostej> (raw)
In-Reply-To: <CA+55aFwhKyjNHuSThuPOejq1uLTXoqHwAtG8cfcx-Sqp83RKSg@mail.gmail.com>
On Fri, Sep 05, 2014 at 04:41:43PM +0100, Linus Torvalds wrote:
> On Fri, Sep 5, 2014 at 8:16 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > How horrible is the below patch (performance wise). It does pretty much
> > the same thing except that percpu_rw_semaphore is a lot saner, its
> > read side performance should be minimal in the absence of writes.
>
> Ugh. Why do any locking at all (whether a new 'perf_rwsem' or using
> 'get_online_cpus()').
>
> Wouldn't it be much nicer to just do what memory management routines
> are *supposed* to do, and get a reference count to the context while
> having a pointer to it?
>
> IOW, why doesn't put_event() just have a
>
> get_ctx(ctx);
> ..
> put_ctx(ctx);
>
> around its use of the context pointer? So if the context ends up being
> migrated during this time, it doesn't get freed.
For the duration of put_event, the event holds a ref on the context. That only
gets decremented _after_ we're done dealing with event->ctx, at the very end of
put_event. Follow the callchain:
put_event(event)
-> _free_event(event)
-> __free_event(event)
-> put_ctx(event->ctx).
As you point out below, the race on event->ctx is the fundamental issue. That
is what results in decrementing the refcount twice (once on a stale event->ctx
pointer).
> However, the more fundamental question is "what protects accesses to
> 'events->ctx'". Why is "put_event()" so special that *it* gets locking
> for the reading of "event->ctx", but none of the other cases of
> reading the ctx pointer gets it or needs it?
The key point is that it doesn't, which is precisely what this patch attempted
to correct.
Regardless you're right that other uses of event->ctx are just as broken. What
perf_pmu_migrate_context failed to take into account was that it is possible to
access an event without going via its owning context and holding ctx->mutex.
> I'm getting the feeling that this race is bigger than just put_event().
We certainly have at least one more race; for event groups perf_read can lock
the stale context.
Mark.
next prev parent reply other threads:[~2014-09-05 17:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-01 18:18 Possible race between CPU hotplug and perf_pmu_migrate_context Mark Rutland
2014-09-01 19:05 ` Peter Zijlstra
2014-09-02 18:58 ` Mark Rutland
2014-09-03 11:50 ` Mark Rutland
2014-09-04 10:44 ` Peter Zijlstra
2014-09-04 11:07 ` Mark Rutland
2014-09-05 15:16 ` Peter Zijlstra
2014-09-05 15:41 ` Linus Torvalds
2014-09-05 16:50 ` Vince Weaver
2014-09-05 16:59 ` Mark Rutland [this message]
2014-09-05 17:31 ` Linus Torvalds
2014-09-05 19:54 ` Peter Zijlstra
2014-09-08 8:39 ` 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=20140905165956.GA28623@leverpostej \
--to=mark.rutland@arm.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=vincent.weaver@maine.edu \
--cc=zheng.z.yan@intel.com \
/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