[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190118120149.GC27931@hirez.programming.kicks-ass.net>
Date: Fri, 18 Jan 2019 13:01:49 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Vince Weaver <vincent.weaver@...ne.edu>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: perf: rdpmc bug when viewing all procs on remote cpu
On Fri, Jan 11, 2019 at 04:52:22PM -0500, Vince Weaver wrote:
> On Thu, 10 Jan 2019, Vince Weaver wrote:
>
> > On Thu, 10 Jan 2019, Vince Weaver wrote:
> >
> > > On Thu, 10 Jan 2019, Vince Weaver wrote:
> > >
> > > > However if you create an all-process attached to CPU event:
> > > > perf_event_open(attr, -1, X, -1, 0);
> > > > the mmap event index is set as if this were a valid event and so the rdpmc
> > > > succeeds even though it shouldn't (we're trying to read an event value
> > > > on a remote cpu with a local rdpmc).
>
> so on further looking at the code, it doesn't appear that rdpmc events are
> explicitly marked as unavailable in the attach-cpu or attach-pid case,
> it's just by luck the check for PERF_EVENT_STATE_ACTIVE catches most of
> the cases?
>
> should an explicit check be added to zero out userpg->index in cases where
> the event being measured is running on a different core?
And how would we konw? We don't know what CPU will be observing the
mmap().
RDPMC fundamentally only makes sense on 'self' (either task or CPU).
Powered by blists - more mailing lists