From: Suzuki Poulose <suzuki.poulose@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
Mike Leach <mike.leach@linaro.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
coresight@lists.linaro.org, Stephen Boyd <swboyd@chromium.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv2 2/4] coresight: tmc-etf: Fix NULL ptr dereference in tmc_enable_etf_sink_perf()
Date: Fri, 23 Oct 2020 14:29:54 +0100 [thread overview]
Message-ID: <728fd89c-78f2-0c5c-0443-c91c62b02f0e@arm.com> (raw)
In-Reply-To: <20201023131628.GY2628@hirez.programming.kicks-ass.net>
On 10/23/20 2:16 PM, Peter Zijlstra wrote:
> On Fri, Oct 23, 2020 at 01:56:47PM +0100, Suzuki Poulose wrote:
>> On 10/23/20 11:54 AM, Peter Zijlstra wrote:
>
>>> I think I'm more confused now :-/
>>>
>>> Where do we use ->owner after event creation? The moment you create your
>>> eventN you create the link to sink0. That link either succeeds (same
>>> 'cookie') or fails.
>>
>> The event->sink link is established at creation. At event::add(), we
>> check the sink is free (i.e, it is inactive) or is used by an event
>> of the same session (this is where the owner field *was* required. But
>> this is not needed anymore, as we cache the "owner" read pid in the
>> handle->rb->aux_priv for each event and this is compared against the
>> pid from the handle currently driving the hardware)
>
> *groan*.. that's going to be a mess with sinks that are shared between
> CPUs :/
>
>>> I'm also not seeing why exactly we need ->owner in the first place.
>>>
>>> Suppose we make the sink0 device return -EBUSY on open() when it is
>>> active. Then a perf session can open the sink0 device, create perf
>>> events and attach them to the sink0 device using
>>> perf_event_attr::config2. The events will attach to sink0 and increment
>>> its usage count, such that any further open() will fail.
>>
>> Thats where we are diverging. The sink device doesn't have any fops. It
>> is all managed by the coresight driver transparent to the perf tool. All
>> the perf tool does is, specifying which sink to use (btw, we now have
>> automatic sink selection support which gets rid of this, and uses
>> the best possible sink e.g, in case of per-CPU sinks).
>
> per-CPU sinks sounds a lot better.
>
> I'm really not convinced it makes sense to do what you do with shared
> sinks though. You'll loose random parts of the execution trace because
> of what the other CPUs do.
The ETM trace protocol has in built TraceID to distinguish the packets
and thus we could decode the trace streams from the shared buffer.
[ But, we don't have buffer overflow interrupts (I am keeping the lid
closed on that can, for the sake of keeping sanity ;-) ), and thus
any shared session could easily loose data unless we tune the AUX
buffer size to a really large buffer ].
>
> Full exclusive sink access is far more deterministic.
>
>>> Once the events are created, the perf tool close()s the sink0 device,
>>> which is now will in-use by the events. No other events can be attached
>>> to it.
>>>
>>> Or are you doing the event->sink mapping every time you do: pmu::add()?
>>> That sounds insane.
>>
>> Sink is already mapped at event create. But yes, the refcount on the
>> sink is managed at start/stop. Thats when we need to make sure that the
>> event being scheduled belongs to the same owner as the one already
>> driving the sink.
>
> pmu::add() I might hope, because pmu::start() is not allowed to fail.
>
Right. If we can't get the sink, we simply truncate the buffer.
>> That way another session could use the same sink if it is free. i.e
>>
>> perf record -e cs_etm/@sink0/u --per-thread app1
>>
>> and
>>
>> perf record -e cs_etm/@sink0/u --per-thread app2
>>
>> both can work as long as the sink is not used by the other session.
>
> Like said above, if sink is shared between CPUs, that's going to be a
> trainwreck :/ Why do you want that?
That ship has sailed. That is how the current generation of systems are,
unfortunately. But as I said, this is changing and there are guidelines
in place to avoid these kind of topologies. With the future
technologies, this will be completely gone.
>
> And once you have per-CPU sinks like mentioned above, the whole problem
> goes away.
True, until then, this is the best we could do.
Suzuki
next prev parent reply other threads:[~2020-10-23 13:29 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-22 10:57 [PATCHv2 0/4] coresight: etf/etb10/etr: Fix NULL pointer dereference crashes Sai Prakash Ranjan
2020-10-22 10:57 ` [PATCHv2 1/4] perf/core: Export is_kernel_event() Sai Prakash Ranjan
2020-10-22 10:57 ` [PATCHv2 2/4] coresight: tmc-etf: Fix NULL ptr dereference in tmc_enable_etf_sink_perf() Sai Prakash Ranjan
2020-10-22 11:32 ` Peter Zijlstra
2020-10-22 12:49 ` Sai Prakash Ranjan
2020-10-22 13:34 ` Peter Zijlstra
2020-10-22 14:23 ` Sai Prakash Ranjan
2020-10-22 13:30 ` Suzuki Poulose
2020-10-22 15:06 ` Peter Zijlstra
2020-10-22 15:32 ` Suzuki Poulose
2020-10-22 21:20 ` Mathieu Poirier
2020-10-23 7:39 ` Peter Zijlstra
2020-10-23 8:49 ` Suzuki Poulose
2020-10-23 9:23 ` Peter Zijlstra
2020-10-23 10:49 ` Suzuki Poulose
2020-10-23 9:41 ` Peter Zijlstra
2020-10-23 10:34 ` Suzuki Poulose
2020-10-23 10:54 ` Peter Zijlstra
2020-10-23 12:56 ` Suzuki Poulose
2020-10-23 13:16 ` Peter Zijlstra
2020-10-23 13:29 ` Suzuki Poulose [this message]
2020-10-23 13:44 ` Peter Zijlstra
2020-10-23 20:37 ` Mathieu Poirier
2020-10-30 7:59 ` Sai Prakash Ranjan
2020-10-30 16:48 ` Mathieu Poirier
2020-10-30 17:26 ` Sai Prakash Ranjan
2020-11-04 17:03 ` Mathieu Poirier
2020-10-22 10:57 ` [PATCHv2 3/4] coresight: etb10: Fix possible NULL ptr dereference in etb_enable_perf() Sai Prakash Ranjan
2020-10-22 10:57 ` [PATCHv2 4/4] coresight: tmc-etr: Fix possible NULL ptr dereference in get_perf_etr_buf_cpu_wide() Sai Prakash Ranjan
2020-10-22 11:10 ` [PATCHv2 0/4] coresight: etf/etb10/etr: Fix NULL pointer dereference crashes Sai Prakash Ranjan
2020-10-22 11:23 ` Sai Prakash Ranjan
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=728fd89c-78f2-0c5c-0443-c91c62b02f0e@arm.com \
--to=suzuki.poulose@arm.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=coresight@lists.linaro.org \
--cc=jolsa@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=saiprakash.ranjan@codeaurora.org \
--cc=swboyd@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).