On Fri, Oct 16, 2026 at 11:46:13AM +0100, James Clark wrote:
Perf AUX setup walks the CoreSight connections to select a sink, build paths and acquire references to the devices and their helpers. Unlike sysfs tracing, it does not hold coresight_mutex. Driver registration and removal can therefore change or free connections while setup walks them. Adding a CTI helper can also reallocate an existing device's output connection array even when the device is already referenced by a path.
I agree that bus traversal and devices acquisition need protection.
Hold coresight_mutex from sink selection through buffer allocation. The allocation must also be protected because ETR buffers can look up a connected CATU. Release the mutex before calling etm_free_aux() on error.
However, my concern is about the locking semantics. We should clearly identify the races that coresight_mutex is intended to protect and limit its usage accordingly. My understanding is that coresight_mutex primarily protects CoreSight bus operations.
Holding it across the entire perf AUX setup might silence AI review warnings, but it may abuse the lock and hide synchronization issues in the CoreSight core APIs. OTOH, I'd say SysFS mode should not acquire such a big lock as well.
BTW, I think this change is a distraction from the per-thread fixes. My understanding is that this series aims to fix multithreading with a shared sink, so we can address device lifetime issues separately.