On 16/03/2026 14:38, Leo Yan wrote:
On Fri, Mar 13, 2026 at 11:18:20AM +0000, Suzuki K Poulose wrote:
[...]
static struct coresight_device *coresight_get_source(struct coresight_path *path) { struct coresight_device *csdev; @@ -1401,6 +1452,8 @@ struct coresight_device *coresight_register(struct coresight_desc *desc) mutex_unlock(&coresight_mutex);
- coresight_set_percpu_source(csdev);
- if (cti_assoc_ops && cti_assoc_ops->add) cti_assoc_ops->add(csdev);
@@ -1427,6 +1480,7 @@ void coresight_unregister(struct coresight_device *csdev) if (cti_assoc_ops && cti_assoc_ops->remove) cti_assoc_ops->remove(csdev);
- coresight_clear_percpu_source(csdev);
Should these be done with the mutex lock held ?
If so, we will create a locking chain:
coresight_mutex -> cpus_read_lock()
Afterwards in patch 18, it uses cpus_read_lock() to protect sysfs knobs, a reversed locking chain will be established:
cpus_read_lock() -> coresight_mutex
LOCKDEP will complain for possible deadlock. This is why this patch avoids to acquire mutex when set / clear per CPU sources.
The question is, what prevents two different CPUs trying to modify the "per_cpu_source" data structure when the CPU is not online.
Suzuki
mutex_lock(&coresight_mutex); etm_perf_del_symlink_sink(csdev); coresight_remove_conns(csdev);