[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201022150609.GI2611@hirez.programming.kicks-ass.net>
Date: Thu, 22 Oct 2020 17:06:09 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Suzuki Poulose <suzuki.poulose@....com>
Cc: Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>,
Mathieu Poirier <mathieu.poirier@...aro.org>,
Mike Leach <mike.leach@...aro.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>, coresight@...ts.linaro.org,
Stephen Boyd <swboyd@...omium.org>,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCHv2 2/4] coresight: tmc-etf: Fix NULL ptr dereference in
tmc_enable_etf_sink_perf()
On Thu, Oct 22, 2020 at 02:30:21PM +0100, Suzuki Poulose wrote:
> On 10/22/20 12:32 PM, Peter Zijlstra wrote:
> > On Thu, Oct 22, 2020 at 04:27:52PM +0530, Sai Prakash Ranjan wrote:
> >
> > > Looking at the ETR and other places in the kernel, ETF and the
> > > ETB are the only places trying to dereference the task(owner)
> > > in tmc_enable_etf_sink_perf() which is also called from the
> > > sched_in path as in the call trace.
> >
> > > @@ -391,6 +392,10 @@ static void *tmc_alloc_etf_buffer(struct coresight_device *csdev,
> > > {
> > > int node;
> > > struct cs_buffers *buf;
> > > + struct task_struct *task = READ_ONCE(event->owner);
> > > +
> > > + if (!task || is_kernel_event(event))
> > > + return NULL;
> >
> >
> > This is *wrong*... why do you care about who owns the events?
> >
>
> This is due to the special case of the CoreSight configuration, where
> a "sink" (where the trace data is captured) is shared by multiple Trace
> units. So, we could share the "sink" for multiple trace units if they
> are tracing the events that belong to the same "perf" session. (The
> userspace tool could decode the trace data based on the TraceID
> in the trace packets). Is there a better way to do this ?
I thought we added sink identification through perf_event_attr::config2
?
Powered by blists - more mailing lists