Concurrent per-thread events results in a WARN on N1SDP which leads to
the realization that per-thread events shouldn't have been sharing sinks
in the first place.
This slips through because different per-thread events will have the
same PID if owned by the same process, and we only check the PID and
nothing else. That results in unexpected WARNs because it looks like we
assumed it couldn't happen (although exclusive PMU rules allow it). But
even if it was supported it would result in trace from the wrong thread
in another event's per-thread buffer, so we should disallow it.
Fix it everywhere the same PID checking logic was copy pasted. Then the
PIDs can be dropped from a few structs as they are now unused.
Signed-off-by: James Clark <james.clark(a)linaro.org>
---
Changes in v3:
- Storing and accessing event owners at runtime causes problems due to
various scenarios of: events (and sibling events) exiting, children
inheriting event FDs, PID reuse, CPU affine events that also have a
target process set but different inherit settings. Fix it by creating
a session ID in etm_setup_aux() and holding the references in it for
the duration of the whole session. (Leo)
- Make the ETR buffer allocator consistent with sink sharing rules by
not doing numeric PID comparisons there either.
- Fix up some Sashiko reports that it sees after interacting with cscfg
and taking extra references to tasks and PIDs.
- Link to v2: https://lore.kernel.org/r/20260709-james-cs-multiple-per-threads-v2-0-10ac7…
Changes in v2:
- Fix inherited events by following event->parent
- Link to v1: https://lore.kernel.org/r/20260709-james-cs-multiple-per-threads-v1-0-d384e…
---
James Clark (8):
coresight: tmc-etr: Don't stop Perf cleanup for active sysfs reads
coresight: configfs: Don't assume active until cscfg_mgr is set
coresight: etm-perf: Flush workqueue before unloading module
coresight: tmc-etr: Prevent per-thread events from sharing a sink
coresight: tmc-etr: Use session ID for buffer ownership
coresight: tmc-etf: Prevent per-thread events from sharing a sink
coresight: etb10: Prevent per-thread events from sharing a sink
coresight: ultrasoc-smb: Prevent per-thread events from sharing a sink
drivers/hwtracing/coresight/coresight-core.c | 28 +--
drivers/hwtracing/coresight/coresight-etb10.c | 33 ++--
drivers/hwtracing/coresight/coresight-etm-perf.c | 79 ++++++++-
drivers/hwtracing/coresight/coresight-etm-perf.h | 15 ++
drivers/hwtracing/coresight/coresight-priv.h | 2 -
drivers/hwtracing/coresight/coresight-syscfg.c | 6 +-
drivers/hwtracing/coresight/coresight-tmc-core.c | 6 +-
drivers/hwtracing/coresight/coresight-tmc-etf.c | 44 ++---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 207 +++++++++++++----------
drivers/hwtracing/coresight/coresight-tmc.h | 30 ++--
drivers/hwtracing/coresight/coresight-trbe.c | 3 +-
drivers/hwtracing/coresight/ultrasoc-smb.c | 25 +--
drivers/hwtracing/coresight/ultrasoc-smb.h | 6 +-
include/linux/coresight.h | 5 +-
14 files changed, 294 insertions(+), 195 deletions(-)
---
base-commit: 98495b5a4d77dd22e106f462b76e1093a55b29a7
change-id: 20260708-james-cs-multiple-per-threads-ed1d25ed1734
Best regards,
--
James Clark <james.clark(a)linaro.org>
On 20/07/26 3:54 AM, Randy Dunlap wrote:
> kernel-doc reports 2 (kernel-doc) lines in coresight.h that don't have
> a beginning '*' in them, so fix these lines.
>
> Also convert struct coresight_trace_id_map to kernel-doc format to
> remove another warning.
>
> Warning: include/linux/coresight.h:173 bad line:
> connected to @src_port. NULL until the device is created
> Warning: include/linux/coresight.h:177 bad line:
> needs to be filtered.
> Warning: include/linux/coresight.h:236 This comment starts with '/**',
> but isn't a kernel-doc comment.
>
> Fixes: ec9903d6cc34 ("coresight: Add support for trace filtering by source")
> Fixes: d49c9cf15f89 ("coresight: Rename connection members to make the direction explicit")
> Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
> ---
> v2: rebase & resend
> v3: rebase & resend
>
> Cc: James Clark <james.clark(a)arm.com>
> Cc: Tao Zhang <quic_taozha(a)quicinc.com>
> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com>
> Cc: coresight(a)lists.linaro.org
> Cc: Danilo Krummrich <dakr(a)kernel.org>
> Cc: Mike Leach <mike.leach(a)arm.com>
> Cc: Leo Yan <leo.yan(a)arm.com>
> Cc: linux-arm-kernel(a)lists.infradead.org
> ---
> include/linux/coresight.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> --- linux-next-20260717.orig/include/linux/coresight.h
> +++ linux-next-20260717/include/linux/coresight.h
> @@ -177,11 +177,11 @@ struct coresight_desc {
> * @dest_port: destination's input port number @src_port is connected to.
> * @dest_fwnode: destination component's fwnode handle.
> * @dest_dev: a @coresight_device representation of the component
> - connected to @src_port. NULL until the device is created
> + * connected to @src_port. NULL until the device is created
> * @link: Representation of the connection as a sysfs link.
> * @filter_src_fwnode: filter source component's fwnode handle.
> * @filter_src_dev: a @coresight_device representation of the component that
> - needs to be filtered.
> + * needs to be filtered.
> *
> * The full connection structure looks like this, where in_conns store
> * references to same connection as the source device's out_conns.
> @@ -234,7 +234,7 @@ struct coresight_sysfs_link {
> #define CORESIGHT_TRACE_IDS_MAX 128
>
> /**
> - * Trace ID map.
> + * struct coresight_trace_id_map - Trace ID map.
> *
> * @used_ids: Bitmap to register available (bit = 0) and in use (bit = 1) IDs.
> * Initialised so that the reserved IDs are permanently marked as
>
But still there are more warnings left in the documentation file
even after the patch applied. Should they be fixed as well ?
./scripts/kernel-doc -none include/linux/coresight.h
Warning: include/linux/coresight.h:216 struct member 'src_dev' not described in 'coresight_connection'
Warning: include/linux/coresight.h:216 struct member 'src_refcnt' not described in 'coresight_connection'
Warning: include/linux/coresight.h:216 struct member 'dest_refcnt' not described in 'coresight_connection'
Warning: include/linux/coresight.h:248 struct member 'cpu_map' not described in 'coresight_trace_id_map'
Warning: include/linux/coresight.h:248 struct member 'lock' not described in 'coresight_trace_id_map'
Warning: include/linux/coresight.h:312 struct member 'perf_sink_id_map' not described in 'coresight_device'
Warning: include/linux/coresight.h:216 struct member 'src_dev' not described in 'coresight_connection'
Warning: include/linux/coresight.h:216 struct member 'src_refcnt' not described in 'coresight_connection'
Warning: include/linux/coresight.h:216 struct member 'dest_refcnt' not described in 'coresight_connection'
Warning: include/linux/coresight.h:248 struct member 'cpu_map' not described in 'coresight_trace_id_map'
Warning: include/linux/coresight.h:248 struct member 'lock' not described in 'coresight_trace_id_map'
Warning: include/linux/coresight.h:312 struct member 'perf_sink_id_map' not described in 'coresight_device'
The current ETMx configuration via sysfs can lead to the following
inconsistencies:
- If a configuration is modified via sysfs while a perf session is
active, the running configuration may differ between before
a sched-out and after a subsequent sched-in.
- If a perf session and sysfs session tries to enable concurrently,
configuration from configfs could be corrupted (etm4).
- There is chance to corrupt drvdata->config if perf session tries
to enabled among handling cscfg_csdev_disable_active_config()
in etm4_disable_sysfs() (etm4).
To resolve these inconsistencies, the configuration should be separated into:
- active_config, which is applied configuration for the current session
- config, which stores the settings configured via sysfs.
and apply configuration from configfs after taking a mode.
Also, This patch set includes some small fixes:
- missing trace id release in etm4x.
- underflow issue for nrseqstate.
- wrong check in etm4x_sspcicrn_present().
- missing call of cscfg_csdev_disable_active_config()
This patch based on coresight tree's next
Patch History
=============
from v8 to v9:
- add feat_csdev_lock guard interface.
- set feat_csdev->drv_spinlock as NULL for etmv4_drvdata.
- https://lore.kernel.org/all/20260629090007.1718746-1-yeoreum.yun@arm.com/
from v7 to v8:
- accept @Leo Yan' suggestion to handle error.
- small minor fixes following @Suzuki' suggestion.
- https://lore.kernel.org/all/20260519154812.254884-1-yeoreum.yun@arm.com/
from v6 to v7:
- rebase on coresight/next
- add ETM_MAX_SEQ_TRANSITIONS define
- remove redundant patch relavent cpu-hotplug as coresight-pm patch
merged.
- https://lore.kernel.org/all/20260422132203.977549-1-yeoreum.yun@arm.com/
from v5 to v6:
- fix missing of calling cscfg_csdev_disable_active_config()
- add rb & fixes tags.
- add ss_status field in etm4x_drvdata to expose STATUS and PENDING bits.
- https://lore.kernel.org/all/20260415165528.3369607-1-yeoreum.yun@arm.com/
from v4 to v5:
- add rb-tag.
- fix underflow issue for nrseqstate.
- fix wrong check in etm4_sspcicrn_present().
- remove redundant fields on etmv4_save_state.
- rename caps->ss_status to ss_cmp.
- fix wrong location of etm4_release_trace_id.
- https://lore.kernel.org/all/20260413142003.3549310-1-yeoreum.yun@arm.com/
from v3 to v4:
- change etm_drvdata->spinlock type to raw_spin_lock_t
- remove redundant call etmX_enable_hw() with starting_cpu() callsback.
- fix missing trace id release.
- add missing docs.
- https://lore.kernel.org/all/20260412175506.412301-1-yeoreum.yun@arm.com/
from v2 to v3:
- fix build error for etm3x.
- fix checkpatch warning.
- https://lore.kernel.org/all/20260410074310.2693385-1-yeoreum.yun@arm.com/
from v1 to v2
- rebased to v7.0-rc7.
- introduce etmX_caps structure to save etmX's capabilities.
- remove ss_status from etmv4_config.
- modify active_config after taking a mode (perf/sysfs).
- https://lore.kernel.org/all/20260317181705.2456271-1-yeoreum.yun@arm.com/
Yeoreum Yun (13):
coresight: etm4x: fix wrong check of etm4x_sspcicrn_present()
coresight: etm4x: fix underflow for usage of (nrseqstate - 1)
coresight: etm4x: fix leaked trace id
coresight: etm4x: fix inconsistencies with sysfs configuration
coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf
enable
coresight: etm3x: fix inconsistencies with sysfs configuration
coresight: etm3x: change drvdata->spinlock type to raw_spin_lock_t
coresight: etm3x: remove redundant cpu online check on
etm_enable_sysfs()
coresight: etm4x: introduce struct etm4_caps
coresight: etm4x: exclude ss_status from drvdata->config
coresight: etm4x: remove s_ex_level from config
coresight: etm4x: remove redundant fields in etmv4_save_state
coresight: etm3x: introduce struct etm_caps
.../hwtracing/coresight/coresight-config.c | 18 +-
.../hwtracing/coresight/coresight-config.h | 26 +
drivers/hwtracing/coresight/coresight-etm.h | 48 +-
.../coresight/coresight-etm3x-core.c | 96 ++--
.../coresight/coresight-etm3x-sysfs.c | 159 +++---
.../hwtracing/coresight/coresight-etm4x-cfg.c | 16 +-
.../coresight/coresight-etm4x-core.c | 454 ++++++++++--------
.../coresight/coresight-etm4x-sysfs.c | 204 ++++----
drivers/hwtracing/coresight/coresight-etm4x.h | 204 ++++----
9 files changed, 682 insertions(+), 543 deletions(-)
base-commit: 98495b5a4d77dd22e106f462b76e1093a55b29a7
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
The current ETMx configuration via sysfs can lead to the following
inconsistencies:
- If a configuration is modified via sysfs while a perf session is
active, the running configuration may differ between before
a sched-out and after a subsequent sched-in.
- If a perf session and sysfs session tries to enable concurrently,
configuration from configfs could be corrupted (etm4).
- There is chance to corrupt drvdata->config if perf session tries
to enabled among handling cscfg_csdev_disable_active_config()
in etm4_disable_sysfs() (etm4).
To resolve these inconsistencies, the configuration should be separated into:
- active_config, which is applied configuration for the current session
- config, which stores the settings configured via sysfs.
and apply configuration from configfs after taking a mode.
Also, This patch set includes some small fixes:
- missing trace id release in etm4x.
- underflow issue for nrseqstate.
- wrong check in etm4x_sspcicrn_present().
- missing call of cscfg_csdev_disable_active_config()
This patch based on coresight tree's next
Patch History
=============
from v7 to v8:
- accept @Leo Yan' suggestion to handle error.
- small minor fixes following @Suzuki' suggestion.
- https://lore.kernel.org/all/20260519154812.254884-1-yeoreum.yun@arm.com/
from v6 to v7:
- rebase on coresight/next
- add ETM_MAX_SEQ_TRANSITIONS define
- remove redundant patch relavent cpu-hotplug as coresight-pm patch
merged.
- https://lore.kernel.org/all/20260422132203.977549-1-yeoreum.yun@arm.com/
from v5 to v6:
- fix missing of calling cscfg_csdev_disable_active_config()
- add rb & fixes tags.
- add ss_status field in etm4x_drvdata to expose STATUS and PENDING bits.
- https://lore.kernel.org/all/20260415165528.3369607-1-yeoreum.yun@arm.com/
from v4 to v5:
- add rb-tag.
- fix underflow issue for nrseqstate.
- fix wrong check in etm4_sspcicrn_present().
- remove redundant fields on etmv4_save_state.
- rename caps->ss_status to ss_cmp.
- fix wrong location of etm4_release_trace_id.
- https://lore.kernel.org/all/20260413142003.3549310-1-yeoreum.yun@arm.com/
from v3 to v4:
- change etm_drvdata->spinlock type to raw_spin_lock_t
- remove redundant call etmX_enable_hw() with starting_cpu() callsback.
- fix missing trace id release.
- add missing docs.
- https://lore.kernel.org/all/20260412175506.412301-1-yeoreum.yun@arm.com/
from v2 to v3:
- fix build error for etm3x.
- fix checkpatch warning.
- https://lore.kernel.org/all/20260410074310.2693385-1-yeoreum.yun@arm.com/
from v1 to v2
- rebased to v7.0-rc7.
- introduce etmX_caps structure to save etmX's capabilities.
- remove ss_status from etmv4_config.
- modify active_config after taking a mode (perf/sysfs).
- https://lore.kernel.org/all/20260317181705.2456271-1-yeoreum.yun@arm.com/
Yeoreum Yun (13):
coresight: etm4x: fix wrong check of etm4x_sspcicrn_present()
coresight: etm4x: fix underflow for usage of (nrseqstate - 1)
coresight: etm4x: introduce struct etm4_caps
coresight: etm4x: exclude ss_status from drvdata->config
coresight: etm4x: remove s_ex_level from config
coresight: etm4x: remove redundant fields in etmv4_save_state
coresight: etm4x: fix leaked trace id
coresight: etm4x: fix inconsistencies with sysfs configuration
coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf
enable
coresight: etm3x: change drvdata->spinlock type to raw_spin_lock_t
coresight: etm3x: introduce struct etm_caps
coresight: etm3x: fix inconsistencies with sysfs configuration
coresight: etm3x: remove redundant cpu online check on
etm_enable_sysfs()
drivers/hwtracing/coresight/coresight-etm.h | 46 +-
.../coresight/coresight-etm3x-core.c | 96 ++--
.../coresight/coresight-etm3x-sysfs.c | 159 +++---
.../hwtracing/coresight/coresight-etm4x-cfg.c | 5 +-
.../coresight/coresight-etm4x-core.c | 454 ++++++++++--------
.../coresight/coresight-etm4x-sysfs.c | 204 ++++----
drivers/hwtracing/coresight/coresight-etm4x.h | 202 ++++----
7 files changed, 639 insertions(+), 527 deletions(-)
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
On Fri, Jul 17, 2026 at 12:41:54AM +0300, Mohamed Ayman wrote:
[...]
> static struct coresight_path *coresight_cpu_get_active_path(enum cs_mode mode)
> {
> struct coresight_device *source;
> - bool is_active = false;
> + struct coresight_path *path = NULL;
>
> - source = coresight_get_percpu_source_ref(smp_processor_id());
> - if (!source)
> - return NULL;
> -
> - if (coresight_get_mode(source) & mode)
> - is_active = true;
> + guard(raw_spinlock_irqsave)(&coresight_dev_lock);
>
> - coresight_put_percpu_source_ref(source);
> + source = per_cpu(csdev_source, smp_processor_id());
> + if (source && (coresight_get_mode(source) & mode))
> + path = source->path;
>
> - /*
> - * It is expected to run in atomic context or with the CPU lock held for
> - * sysfs mode, so it cannot be preempted to disable the path. Here
> - * returns the active path pointer without concern that its state may
> - * change. Since the build path has taken a reference on the component,
> - * the path can be safely used by the caller.
> - */
Please keep the comment, as it helps explain why the path pointer can be
returned and safely used by the caller.
> - return is_active ? source->path : NULL;
> + return path;
With above update:
Reviewed-by: Leo Yan <leo.yan(a)arm.com>
Just a thought: we could view this in two stages.
1) The first stage is building the CoreSight path, where we need to
ensure the involved modules remain bound while the path is being
established.
2) Once the path has been built and the device mode is enabled, we
enter the runtime stage. From that point on, observing the device
mode as enabled guarantees that the associated data structures
can be accessed safely.
I would leave this to maintainers for a call in case any concerns on
lifetime management.
On Fri, Jul 17, 2026 at 06:12:01PM +0200, Sebastian Andrzej Siewior wrote:
[...]
> > The raw spinlock (coresight_dev_lock) serializes access to the per-CPU
> > csdev_source pointer. It does not guarantee the lifetime of the source
> > or its _parent_ device. coresight_unregister() is not only reached from
> > module unload; it can also be called when a driver is unbind, for
> > example DT overlay removal or device hotplug/unplug.
>
> But doesn't coresight_unregister() block on the coresight_dev_lock here?
Fair point.
coresight_cpu_get_active_path() can safely access the source while
holding coresight_dev_lock. Unregistration will be blocked until the
access from the CPU PM notifier has finished.
> > I think a proper fix needs a clearer lifetime model for an active
> > session. E.g., we could consider to call device_link_add() to prevent
> > device unbind / unregister, and unlink device when the session is
> > finished. Once that is in place, the CPU PM notifier can safely use the
> > active path without get_device()/put_device() pair anymore.
>
> Right. I am also not sure about lifetime of coresight_device::path.
coresight_device::path is a runtime pointer that is valid only while
the device is enabled.
Since both the path and the device mode are updated atomically on the
local CPU, observing the device mode as enabled guarantees that the
corresponding coresight_device::path is valid.
Thanks,
Leo
cs_etm__get_trace() returns an int, but it used to return etmq->buf_len
on success. That value comes from auxtrace_buffer::size, which is a
size_t. For a large AUX trace block, returning the byte count through an
int can overflow and make a valid buffer look like a negative error.
The callers do not need the actual byte count from cs_etm__get_trace().
The buffer length is already stored in the etmq->buf_len. The callers
only need to distinguish three states:
< 0: error
= 0: no more AUX buffers
> 0: data is available
Make cs_etm__get_trace() return 0 for all non-error cases and use
etmq->buf_len to indicate whether a new buffer was found. Then make
cs_etm__get_data_block() return 1 whenever data is available, instead of
returning the buffer length.
Also refactor cs_etm__get_data_block() to make its return value
semantics clearer.
Reported-by: Suyash Mahar <smahar(a)meta.com>
Fixes: 8224531cf5a1 ("perf cs-etm: Modularize auxtrace_buffer fetch function")
Signed-off-by: Leo Yan <leo.yan(a)arm.com>
---
tools/perf/util/cs-etm.c | 46 ++++++++++++++++++++++++++--------------------
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 95e3ec1171acc8442d8539a72a26a1a5a53a2f37..114b3cd2da495e54e78df8fbd707898312f95079 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1467,8 +1467,7 @@ cs_etm__get_trace(struct cs_etm_queue *etmq)
etmq->buf_used = 0;
etmq->buf_len = aux_buffer->size;
etmq->buf = aux_buffer->data;
-
- return etmq->buf_len;
+ return 0;
}
/*
@@ -2151,26 +2150,33 @@ static int cs_etm__get_data_block(struct cs_etm_queue *etmq)
{
int ret;
- if (!etmq->buf_len) {
- ret = cs_etm__get_trace(etmq);
- if (ret <= 0)
- return ret;
- /*
- * We cannot assume consecutive blocks in the data file
- * are contiguous, reset the decoder to force re-sync.
- */
- ret = cs_etm_decoder__reset(etmq->decoder);
- if (ret)
- return ret;
+ /* The current block is not finished */
+ if (etmq->buf_len)
+ return 1;
- /*
- * Since the decoder is reset, this causes a global trace
- * discontinuity. Flush all thread stacks.
- */
- cs_etm__flush_all_stack(etmq);
- }
+ ret = cs_etm__get_trace(etmq);
+ if (ret < 0)
+ return ret;
+
+ /* No more buffer to read */
+ if (!etmq->buf_len)
+ return 0;
+
+ /*
+ * We cannot assume consecutive blocks in the data file
+ * are contiguous, reset the decoder to force re-sync.
+ */
+ ret = cs_etm_decoder__reset(etmq->decoder);
+ if (ret)
+ return ret;
+
+ /*
+ * Since the decoder is reset, this causes a global trace
+ * discontinuity. Flush all thread stacks.
+ */
+ cs_etm__flush_all_stack(etmq);
- return etmq->buf_len;
+ return 1;
}
static bool cs_etm__is_svc_instr(struct cs_etm_queue *etmq,
---
base-commit: e01c7bd5b1eece254bcbf282db066b12c4815d21
change-id: 20260720-perf_cs_etm_fix_big_size-ec5608f767df
Best regards,
--
Leo Yan <leo.yan(a)arm.com>
On Fri, Jul 17, 2026 at 12:41:54AM +0300, Mohamed Ayman wrote:
[...]
> static struct coresight_path *coresight_cpu_get_active_path(enum cs_mode mode)
> {
> struct coresight_device *source;
> - bool is_active = false;
> + struct coresight_path *path = NULL;
>
> - source = coresight_get_percpu_source_ref(smp_processor_id());
> - if (!source)
> - return NULL;
> -
> - if (coresight_get_mode(source) & mode)
> - is_active = true;
> + guard(raw_spinlock_irqsave)(&coresight_dev_lock);
>
> - coresight_put_percpu_source_ref(source);
> + source = per_cpu(csdev_source, smp_processor_id());
> + if (source && (coresight_get_mode(source) & mode))
> + path = source->path;
I agree the get_device()/put_device() pair in
coresight_cpu_get_active_path() is not a good fit for CPU PM notifier,
because the put_device() can become the final put while IRQ is disabled.
However, my understanding is this patch might cause UAF issue that the
existing code is intended to prevent.
The raw spinlock (coresight_dev_lock) serializes access to the per-CPU
csdev_source pointer. It does not guarantee the lifetime of the source
or its _parent_ device. coresight_unregister() is not only reached from
module unload; it can also be called when a driver is unbind, for
example DT overlay removal or device hotplug/unplug.
This is why the UAF issue Sashiko mentioned in patch 03 of [1]. A built
CoreSight path currently grabs references for the path components, which
keeps module alive, but that is not the same as preventing the parent
device/driver from being unbound and tearing down CoreSight device data
while an active session still has raw pointers.
There are also similar race window before the path is built: for
example etm_setup_aux() has to look up source/sink state before
coresight_build_path() establishes the path, so it might access
released source/sink data if device is unbound.
I think a proper fix needs a clearer lifetime model for an active
session. E.g., we could consider to call device_link_add() to prevent
device unbind / unregister, and unlink device when the session is
finished. Once that is in place, the CPU PM notifier can safely use the
active path without get_device()/put_device() pair anymore.
Hope this is clear and makes sense.
Thanks,
Leo
[1] https://sashiko.dev/#/patchset/20260405-arm_coresight_path_power_management…
Hi Mohamed & Sebastian,
On Fri, Jul 17, 2026 at 10:14:53AM +0200, Sebastian Andrzej Siewior wrote:
[...]
> There is coresight_put_percpu_source_ref() with holds coresight_dev_lock
> during a put_cpu. I don't know why the lock is held, it is not obvious
> to me. But it will lead to a similar problem if the put actually invokes
> the release callback.
Sorry I am a bit late to join the discussion.
Essentially, this is about how to manage a module's lifetime correctly
so that the CPU PM notifier can safely access a device. There is an edge
case where the CPU PM notifier is accessing the device while, at the
same time, the module is being unloaded and the device's resources are
being released.
For now, I'd suggest please hold on this patch. Give me a bit time to
study this thread, I will share back more details.
Thanks,
Leo