mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Clark <james.clark@linaro.org>
To: Leo Yan <leo.yan@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, coresight@lists.linaro.org,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Mike Leach <mike.leach@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Tamas Petz <tamas.petz@arm.com>,
	Tamas Zsoldos <tamas.zsoldos@arm.com>,
	Suyash Mahar <smahar@meta.com>, Amir Ayupov <aaupov@fb.com>
Subject: Re: [PATCH v2 19/23] coresight: trbe: Reload the AUX buffer on overflow restart
Date: Tue, 10 Nov 2026 15:12:06 +0000	[thread overview]
Message-ID: <d93b9120-197d-4b01-a9ab-8df01657716d@linaro.org> (raw)
In-Reply-To: <20261016-trbe_enable_disable_irq_handle_refactor-v2-19-3f57cf3199b1@arm.com>



On 16/10/2026 17:55, Leo Yan wrote:
> PERF_EVENT_IOC_SET_OUTPUT lets events share another event's mapped output
> buffer. For AUX events, this also selects the associated AUX area and
> sink configuration. Perf normally establishes this sharing during setup.
> 
> Consider the following hypothetical live-redirection sequence, permitted
> by the inspected perf-core paths. P is a parent event and C is its
> inherited event, with C->parent = P. A and B are mapped AUX destination
> buffers owned by separate, disabled cs_etm events in different task
> contexts. All three are per-task events restricted to the same CPU, with
> compatible output settings. P has no mmap of its own, allowing its output
> to be redirected while A and B remain mapped through their owner events.
> 
> 1. P's output is redirected to A. C inherits from P and begins tracing
>     on the selected CPU, so its open AUX transaction and TRBE hardware
>     both use A. P can be inactive while C is running because their
>     events are scheduled with their respective tasks.
> 2. A userspace controller calls PERF_EVENT_IOC_SET_OUTPUT on P to select
>     B. ring_buffer_attach() calls perf_event_stop(P, 0), which returns for
>     inactive P without stopping C. P->rb now selects B, but C's existing
>     handle and hardware still use A.
> 3. C's next buffer overflow invokes trbe_handle_overflow() from the IRQ
>     handler. It saves buf for A, ends that AUX transaction, then calls
>     perf_aux_output_begin(handle, C). AUX begin follows C->parent and
>     reads P's current rb, rebinding the same handle to B.
> 
> This is a hypothetical API sequence, not a reproduced TRBE failure or
> an observed buffer switch in normal perf record operation.
> 
> Without reloading buf, __arm_trbe_enable() calculates the next buffer
> using B through the handle, but its workaround and hardware setup still
> receive A. If B has never been enabled, its missing CPU association can
> cause the normal-offset calculation to dereference NULL. With a snapshot
> buffer, hardware may instead keep using A while perf accounts output to B.
> 
> Reload the sink configuration after perf_aux_output_begin() so the buffer
> and handle refer to the same AUX transaction. If the buffer is missing or
> its CPU association does not match the interrupt's CPU data, truncate the
> new transaction and leave TRBE disabled. Truncation requests perf to stop
> the event; a subsequent normal restart installs the buffer and its CPU
> association through the sink enable path.
> 
> Stopping inherited writers during output redirection remains a separate
> perf-core fix.
> 

Shouldn't we do that instead of this? It seems much better to fix this 
in perf core rather than here which is hard to understand and appears to 
be a bit hacky, and doesn't apply to all users of aux buffers. I would 
expect that even when using PERF_EVENT_IOC_SET_OUTPUT, the buffer should 
be consistent between start and stops from the point of view of 
individual drivers. It makes sense to add a workaround in the driver if 
we can't control that behavior, but the code is in the same repo. Maybe 
we could even just leave this patch out and do the core fix later?

Unrelated to this, the sashiko report that says there is an out of 
bounds read if the output is switched to an ETF buffer seems to be 
pre-existing. But it's something worth thinking about.

> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
>   drivers/hwtracing/coresight/coresight-trbe.c | 14 ++++++++++++++
>   1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
> index 2328aab0a084a0ac123e950f846f404d120ec2c0..f1f102df6c387f53feaa12b89d3df89f734afcdb 100644
> --- a/drivers/hwtracing/coresight/coresight-trbe.c
> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
> @@ -1161,6 +1161,20 @@ static int trbe_handle_overflow(struct trbe_cpudata *cpudata)
>   	if (!event_data)
>   		return -EINVAL;
>   
> +	/*
> +	 * Reload the buffer after perf_aux_output_begin() so it matches the
> +	 * handle. A race with PERF_EVENT_IOC_SET_OUTPUT may select a buffer
> +	 * that has not been installed on this CPU and has no valid cpudata.
> +	 * If the buffer is missing or its CPU association does not match,
> +	 * truncate the trace to stop the event. A subsequent normal restart
> +	 * installs the buffer and its CPU association through sink enable.
> +	 */
> +	buf = etm_perf_sink_config(handle);
> +	if (!buf || buf->cpudata != cpudata) {
> +		trbe_truncate_event(handle);
> +		return -EINVAL;
> +	}
> +
>   	return __arm_trbe_enable(buf, handle);
>   }
>   
> 

  reply	other threads:[~2026-11-10 15:12 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16 16:54 [PATCH v2 00/23] coresight: trbe: Refactor buffer and IRQ handling Leo Yan
2026-10-16 16:54 ` [PATCH v2 01/23] arm64/sysreg: Define TRBSR_EL1.EC event classes Leo Yan
2026-11-10 15:28   ` James Clark
2026-10-16 16:55 ` [PATCH v2 02/23] coresight: trbe: Make watermark range check overflow safe in __trbe_normal_offset() Leo Yan
2026-11-10 15:28   ` James Clark
2026-10-16 16:55 ` [PATCH v2 03/23] coresight: trbe: Use helpers for checking errata Leo Yan
2026-11-10 15:29   ` James Clark
2026-10-16 16:55 ` [PATCH v2 04/23] coresight: trbe: Check the buffer association before IRQ validation Leo Yan
2026-11-10 15:29   ` James Clark
2026-10-16 16:55 ` [PATCH v2 05/23] coresight: trbe: Validate perf handle before using sink data Leo Yan
2026-11-10 15:29   ` James Clark
2026-10-16 16:55 ` [PATCH v2 06/23] coresight: trbe: Drop redundant disable from enable path Leo Yan
2026-11-09 16:27   ` James Clark
2026-10-16 16:55 ` [PATCH v2 07/23] coresight: trbe: Publish the session after successful enable Leo Yan
2026-11-10 15:30   ` James Clark
2026-10-16 16:55 ` [PATCH v2 08/23] coresight: trbe: Clear stale external abort status Leo Yan
2026-11-10 15:30   ` James Clark
2026-10-16 16:55 ` [PATCH v2 09/23] coresight: trbe: Clear TRBSR status at stop sites Leo Yan
2026-11-09 16:40   ` James Clark
2026-11-09 16:51     ` James Clark
2026-11-09 22:51   ` Suzuki K Poulose
2026-11-10  8:48     ` Leo Yan
2026-11-10 15:25       ` Suzuki K Poulose
2026-10-16 16:55 ` [PATCH v2 10/23] coresight: trbe: Drop redundant disables Leo Yan
2026-11-10 15:31   ` James Clark
2026-10-16 16:55 ` [PATCH v2 11/23] coresight: trbe: Assign the perf handle in enable and disable Leo Yan
2026-11-10 15:31   ` James Clark
2026-10-16 16:55 ` [PATCH v2 12/23] coresight: trbe: Decode TRBSR status codes Leo Yan
2026-11-10 15:32   ` James Clark
2026-10-16 16:55 ` [PATCH v2 13/23] coresight: trbe: Simplify wrap status handling Leo Yan
2026-11-10 15:32   ` James Clark
2026-10-16 16:55 ` [PATCH v2 14/23] coresight: trbe: Treat access not allowed stops as fatal Leo Yan
2026-11-10 15:33   ` James Clark
2026-10-16 16:55 ` [PATCH v2 15/23] coresight: trbe: Report truncated trace on buffer update errors Leo Yan
2026-11-10 15:33   ` James Clark
2026-10-16 16:55 ` [PATCH v2 16/23] coresight: trbe: Always classify TRBSR when updating buffer Leo Yan
2026-11-10 15:34   ` James Clark
2026-10-16 16:55 ` [PATCH v2 17/23] coresight: trbe: Calculate trace size across buffer wrap Leo Yan
2026-11-10 15:34   ` James Clark
2026-10-16 16:55 ` [PATCH v2 18/23] coresight: trbe: Keep the perf handle in per-CPU data Leo Yan
2026-11-10 15:34   ` James Clark
2026-10-16 16:55 ` [PATCH v2 19/23] coresight: trbe: Reload the AUX buffer on overflow restart Leo Yan
2026-11-10 15:12   ` James Clark [this message]
2026-10-16 16:55 ` [PATCH v2 20/23] coresight: trbe: Add fault action argument to trbe_handle_overflow() Leo Yan
2026-11-10 15:34   ` James Clark
2026-10-16 16:55 ` [PATCH v2 21/23] coresight: trbe: Read TRBSR after prohibiting and flushing trace Leo Yan
2026-11-10 15:24   ` James Clark
2026-10-16 16:55 ` [PATCH v2 22/23] coresight: trbe: Restart trace source for stopped buffers Leo Yan
2026-11-10 15:35   ` James Clark
2026-10-16 16:55 ` [PATCH v2 23/23] coresight: trbe: Report trace gaps with PARTIAL instead of COLLISION Leo Yan
2026-11-10 15:35   ` James Clark

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=d93b9120-197d-4b01-a9ab-8df01657716d@linaro.org \
    --to=james.clark@linaro.org \
    --cc=aaupov@fb.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=anshuman.khandual@arm.com \
    --cc=coresight@lists.linaro.org \
    --cc=leo.yan@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.leach@arm.com \
    --cc=smahar@meta.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tamas.petz@arm.com \
    --cc=tamas.zsoldos@arm.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

all inboxes | Powered by JetHome®