On Mon, Jun 29, 2026 at 10:00:01AM +0100, Yeoreum Yun wrote:
[...]
@@ -619,27 +622,52 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata) static void etm4_enable_sysfs_smp_call(void *info) { struct etm4_enable_arg *arg = info;
- struct etmv4_drvdata *drvdata; struct coresight_device *csdev;
- unsigned long cfg_hash;
- int preset;
if (WARN_ON(!arg)) return;
- csdev = arg->drvdata->csdev;
- drvdata = arg->drvdata;
- csdev = drvdata->csdev; if (!coresight_take_mode(csdev, CS_MODE_SYSFS)) { /* Someone is already using the tracer */ arg->rc = -EBUSY; return; }
- arg->rc = etm4_enable_hw(arg->drvdata);
- drvdata->active_config = arg->config;
- /* The tracer didn't start */
- /* enable any config activated by configfs */
- cscfg_config_sysfs_get_active_cfg(&cfg_hash, &preset);
- if (cfg_hash) {
arg->rc = cscfg_csdev_enable_active_config(csdev,cfg_hash,preset);if (arg->rc)goto err;- }
I try best to not paste any non-sense AI reviews, record one from Sashiko [1]:
| If a user writes to a sysfs attribute like pe_sel_store(), it acquires | drvdata->spinlock without disabling interrupts. If an IPI is then handled | on the same CPU, etm4_enable_sysfs_smp_call() will call | cscfg_csdev_enable_active_config() which attempts to acquire the exact | same spinlock, hanging the CPU."
The flow for acquiring drvdata->spinlock in SMP call is:
etm4_enable_sysfs_smp_call() `> cscfg_csdev_enable_active_config() `> cscfg_csdev_enable_config() `> cscfg_prog_config() `> cscfg_set_on_enable() `> raw_spin_lock_irqsave(feat_csdev->drv_spinlock, flags);
We might expect the complaint from LOCKDEP with this patch.
To be clear, I am not object to this patch, just record in case we will handle it later.
[1] https://sashiko.dev/#/patchset/20260629090007.1718746-1-yeoreum.yun%40arm.co...