[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwhKyjNHuSThuPOejq1uLTXoqHwAtG8cfcx-Sqp83RKSg@mail.gmail.com>
Date: Fri, 5 Sep 2014 08:41:43 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Mark Rutland <mark.rutland@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Yan Zheng <zheng.z.yan@...el.com>,
Stephane Eranian <eranian@...gle.com>,
Ingo Molnar <mingo@...nel.org>,
Vince Weaver <vincent.weaver@...ne.edu>
Subject: Re: Possible race between CPU hotplug and perf_pmu_migrate_context
On Fri, Sep 5, 2014 at 8:16 AM, Peter Zijlstra <peterz@...radead.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.
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?
I'm getting the feeling that this race is bigger than just put_event().
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists