From: Adrian Hunter <adrian.hunter@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Heiko Carstens <hca@linux.ibm.com>,
Thomas Richter <tmricht@linux.ibm.com>,
Hendrik Brueckner <brueckner@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Mike Leach <mike.leach@linaro.org>,
James Clark <james.clark@arm.com>,
coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
Yicong Yang <yangyicong@hisilicon.com>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
Will Deacon <will@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>, Andi Kleen <ak@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH V8 02/12] perf/x86/intel/pt: Add support for pause / resume
Date: Thu, 11 Jul 2024 16:35:00 +0300 [thread overview]
Message-ID: <0c59b36f-9b83-475f-b3b2-7fe3649412f4@intel.com> (raw)
In-Reply-To: <20240701104659.GB20127@noisy.programming.kicks-ass.net>
On 1/07/24 13:46, Peter Zijlstra wrote:
> On Fri, Jun 28, 2024 at 09:51:01AM +0300, Adrian Hunter wrote:
>
>> @@ -534,7 +537,20 @@ static void pt_config(struct perf_event *event)
>> reg |= (event->attr.config & PT_CONFIG_MASK);
>>
>> event->hw.config = reg;
>> +
>> + /*
>> + * Allow resume before starting so as not to overwrite a value set by a
>> + * PMI.
>> + */
>> + WRITE_ONCE(pt->resume_allowed, 1);
> barrier();
>> pt_config_start(event);
> barrier();
>> + /*
>> + * Allow pause after starting so its pt_config_stop() doesn't race with
>> + * pt_config_start().
>> + */
>> + WRITE_ONCE(pt->pause_allowed, 1);
>
> IIRC you need those barrier()s, because if the compiler 'helpfully'
> inlines the static pt_config_start(), you loose your sequence point and
> things can get re-ordered. WRITE_ONCE() only ensures the store is whole
> and ordered against other volatile ops, but not against much else.
Yes barriers are needed. gcc even says:
...an implementation is free to reorder and combine volatile
accesses that occur between sequence points...
Accesses to non-volatile objects are not ordered with respect
to volatile accesses.
https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html
>
>> }
>>
>> static void pt_config_stop(struct perf_event *event)
>> @@ -1511,6 +1527,7 @@ void intel_pt_interrupt(void)
>> buf = perf_aux_output_begin(&pt->handle, event);
>> if (!buf) {
>> event->hw.state = PERF_HES_STOPPED;
>> + pt->resume_allowed = 0;
>> return;
>> }
>>
>> @@ -1519,6 +1536,7 @@ void intel_pt_interrupt(void)
>> ret = pt_buffer_reset_markers(buf, &pt->handle);
>> if (ret) {
>> perf_aux_output_end(&pt->handle, 0);
>> + pt->resume_allowed = 0;
>> return;
>> }
>>
>
> Above you WRITE_ONCE() on ->resume_allowed, here you do not. Some *SAN
> thing or other is bound to get upset about things like that.
>
>> @@ -1573,6 +1591,26 @@ static void pt_event_start(struct perf_event *event, int mode)
>> struct pt *pt = this_cpu_ptr(&pt_ctx);
>> struct pt_buffer *buf;
>>
>> + if (mode & PERF_EF_RESUME) {
>> + if (READ_ONCE(pt->resume_allowed)) {
>
> At this point I seem to have lost the plot, how do ->resume_allowed and
> ->aux_paused interact?
This is assuming there is no guaranteed order that events
in the group are started / stopped, so there is a need to
protect against pt being resumed when it is not yet configured,
or when it is in the process of being stopped.
Updates to event->hw.state don't happen at quite the right
places to be used instead, and the needs of resume are slightly
different to pause.
resume_allowed means pt is configured and so ->start(PERF_EF_RESUME)
can actually safely start pt. aux_paused is separate and takes
effect when there is a regular start.
>
>> + u64 status;
>> +
>> + /*
>> + * Only if the trace is not active and the error and
>> + * stopped bits are clear, is it safe to start, but a
>> + * PMI might have just cleared these, so resume_allowed
>> + * must be checked again also.
>> + */
>> + rdmsrl(MSR_IA32_RTIT_STATUS, status);
>> + if (!(status & (RTIT_STATUS_TRIGGEREN |
>> + RTIT_STATUS_ERROR |
>> + RTIT_STATUS_STOPPED)) &&
>> + READ_ONCE(pt->resume_allowed))
>> + pt_config_start(event);
>> + }
>> + return;
>> + }
>> +
>> buf = perf_aux_output_begin(&pt->handle, event);
>> if (!buf)
>> goto fail_stop;
>> @@ -1601,6 +1639,16 @@ static void pt_event_stop(struct perf_event *event, int mode)
>> {
>> struct pt *pt = this_cpu_ptr(&pt_ctx);
>>
>> + if (mode & PERF_EF_PAUSE) {
>> + if (READ_ONCE(pt->pause_allowed))
>> + pt_config_stop(event);
>> + return;
>> + }
>> +
>> + /* Protect against racing */
>
> No F1 cars allowed? Sure the comment can elucidate the reader as to what
> actual race one is concerned about, no?
Yeah this needs more comments.
>
>> + WRITE_ONCE(pt->pause_allowed, 0);
>> + WRITE_ONCE(pt->resume_allowed, 0);
>> +
>> /*
>> * Protect against the PMI racing with disabling wrmsr,
>> * see comment in intel_pt_interrupt().
>> @@ -1659,8 +1707,12 @@ static long pt_event_snapshot_aux(struct perf_event *event,
>> /*
>> * Here, handle_nmi tells us if the tracing is on
>> */
>> - if (READ_ONCE(pt->handle_nmi))
>> + if (READ_ONCE(pt->handle_nmi)) {
>> + /* Protect against racing */
>> + WRITE_ONCE(pt->pause_allowed, 0);
>> + WRITE_ONCE(pt->resume_allowed, 0);
>
> barrier()?
>
>> pt_config_stop(event);
>> + }
>>
>> pt_read_offset(buf);
>> pt_update_head(pt);
>> @@ -1677,8 +1729,11 @@ static long pt_event_snapshot_aux(struct perf_event *event,
>> * Compiler barrier not needed as we couldn't have been
>> * preempted by anything that touches pt->handle_nmi.
>> */
>> - if (pt->handle_nmi)
>> + if (pt->handle_nmi) {
>> + WRITE_ONCE(pt->resume_allowed, 1);
>> pt_config_start(event);
>> + WRITE_ONCE(pt->pause_allowed, 1);
>
> barrier() went missing again?
>
>> + }
>>
>> return ret;
>> }
next prev parent reply other threads:[~2024-07-11 13:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-28 6:50 [PATCH V8 00/12] perf/core: Add ability for an event to "pause" or "resume" AUX area tracing Adrian Hunter
2024-06-28 6:51 ` [PATCH V8 01/12] perf/core: Add aux_pause, aux_resume, aux_start_paused Adrian Hunter
2024-07-01 10:26 ` Peter Zijlstra
2024-07-11 10:42 ` Adrian Hunter
2024-07-11 11:51 ` Peter Zijlstra
2024-07-01 10:52 ` Peter Zijlstra
2024-07-11 11:14 ` Adrian Hunter
2024-06-28 6:51 ` [PATCH V8 02/12] perf/x86/intel/pt: Add support for pause / resume Adrian Hunter
2024-07-01 10:46 ` Peter Zijlstra
2024-07-11 13:35 ` Adrian Hunter [this message]
2024-06-28 6:51 ` [PATCH V8 03/12] perf/x86/intel: Do not enable large PEBS for events with aux actions or aux sampling Adrian Hunter
2024-06-28 6:51 ` [PATCH V8 04/12] perf tools: Enable evsel__is_aux_event() to work for ARM/ARM64 Adrian Hunter
2024-06-28 6:51 ` [PATCH V8 05/12] perf tools: Enable evsel__is_aux_event() to work for S390_CPUMSF Adrian Hunter
2024-06-28 6:51 ` [PATCH V8 06/12] perf tools: Add aux_start_paused, aux_pause and aux_resume Adrian Hunter
2024-06-28 6:51 ` [PATCH V8 07/12] perf tools: Add aux-action config term Adrian Hunter
2024-06-28 6:51 ` [PATCH V8 08/12] perf tools: Parse aux-action Adrian Hunter
2024-06-28 6:51 ` [PATCH V8 09/12] perf tools: Add missing_features for aux_start_paused, aux_pause, aux_resume Adrian Hunter
2024-06-28 6:51 ` [PATCH V8 10/12] perf intel-pt: Improve man page format Adrian Hunter
2024-06-28 6:51 ` [PATCH V8 11/12] perf intel-pt: Add documentation for pause / resume Adrian Hunter
2024-06-28 6:51 ` [PATCH V8 12/12] perf intel-pt: Add a test " Adrian Hunter
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=0c59b36f-9b83-475f-b3b2-7fe3649412f4@intel.com \
--to=adrian.hunter@intel.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=brueckner@linux.ibm.com \
--cc=coresight@lists.linaro.org \
--cc=hca@linux.ibm.com \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=jolsa@kernel.org \
--cc=jonathan.cameron@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=suzuki.poulose@arm.com \
--cc=tmricht@linux.ibm.com \
--cc=will@kernel.org \
--cc=yangyicong@hisilicon.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;
as well as URLs for NNTP newsgroup(s).