[PATCH v6 02/19] coresight: Set per-CPU source pointer

Suzuki K Poulose suzuki.poulose at arm.com
Mon Mar 16 10:49:47 PDT 2026


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);
>>>
>>




More information about the linux-arm-kernel mailing list