[PATCH v4 09/15] coresight: Save activated path into source device

Leo Yan leo.yan at arm.com
Mon Nov 17 07:16:12 PST 2025


On Tue, Nov 11, 2025 at 02:10:10PM +0000, Suzuki Kuruppassery Poulose wrote:

[...]

> > @@ -399,13 +399,50 @@ int coresight_enable_source(struct coresight_device *csdev,
> >   			    struct perf_event *event, enum cs_mode mode,
> >   			    struct coresight_path *path)
> >   {
> > -	return source_ops(csdev)->enable(csdev, event, mode, path);
> > +	int ret;
> > +
> > +	/*
> > +	 * Record the path in the source device. The path pointer is first
> > +	 * assigned, followed by transitioning from DISABLED mode to an enabled
> > +	 * state on the target CPU. Conversely, during the disable flow, the
> > +	 * device mode is set to DISABLED before the path pointer is cleared.
> > +	 *
> > +	 * This ordering ensures the path pointer to be safely access under the
> > +	 * following race condition:
> > +	 *
> > +	 *  CPU(a)                          CPU(b)
> > +	 *
> > +	 *  coresight_enable_source()
> > +	 *    STORE source->path;
> > +	 *    smp_mb();
> > +	 *    source_ops(csdev)->enable();
> > +	 *                              `-> etm4_enable_sysfs_smp_call()
> > +	 *                                    STORE source->mode;
> > +	 *
> > +	 * This sequence ensures that accessing the path pointer is safe when
> > +	 * the device is in enabled mode.
> > +	 */
> > +	csdev->path = path;
> > +
> > +	/* Synchronization between csdev->path and csdev->mode */
> > +	smp_mb();
> > +
> > +	ret = source_ops(csdev)->enable(csdev, event, mode, path);
> 
> What happens if the csdev is already enabled ? We corrupt the csdev->path ?
> Can we not move this into the source devices and let them
> handle it gracefully, as they do for the "mode" ?

Indeed.  I will move the path setting on the target CPU, along with
setting mode.

> To address James' comment on reusing the sysfs path, I think we could
> make this a global thing for all types of source/mode.

In the previous version, I used a global variable to store path pointer,
but in this version I moved back the path pointer into csdev for two
reasons:

- Except we need to store (per-CPU) ETM's path pointer, we also need
  extra data structure for storing system source.

- For both perf and sysfs sessions, we need to retrieve path pointer
  based on the given source's csdev.  And we need to use the source
  device's mode to decide if the path poiter is valid.

For above reasons, I prefer to store the path pointer into the source
device's csdev - based on the csdev, it is easy to retrieve path pointer,
and it is easy to access the other associated info (mode).

Thanks,
Leo



More information about the linux-arm-kernel mailing list