Dropping the last reference to a coresight_device can trigger a kernel
panic on PREEMPT_RT builds due to a "scheduling while atomic" violation.

When the CPU enters an idle state, coresight_cpu_pm_notify() is invoked
with local interrupts disabled. It calls coresight_cpu_get_active_path(),
which currently uses coresight_get_percpu_source_ref() to get a kobject
reference, and then immediately drops it with coresight_put_percpu_source_ref().

If this put_device() call drops the very last reference (e.g., due to a
concurrent device unregistration), it synchronously triggers the release
cascade. On PREEMPT_RT, free_percpu() takes a sleeping spinlock_t.
Furthermore, any parent device in the release chain might also acquire
sleeping locks, causing a system crash in the atomic PM context.

Fix this by eliminating the get/put dance entirely in the PM notifier path.
Since coresight_cpu_pm_notify() runs with IRQs disabled, it is safe to
read the per-cpu source pointer directly under the coresight_dev_lock,
check the mode, and return the path without unnecessarily manipulating the
kobject refcount.

Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Mohamed Ayman <mohamedaymanworkspace@gmail.com>
---
 drivers/hwtracing/coresight/coresight-core.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 6d65c43d5..9461fac9f 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -1850,16 +1850,13 @@ static void coresight_release_device_list(void)
 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
@@ -1868,7 +1865,7 @@ static struct coresight_path *coresight_cpu_get_active_path(enum cs_mode mode)
 	 * change. Since the build path has taken a reference on the component,
 	 * the path can be safely used by the caller.
 	 */
-	return is_active ? source->path : NULL;
+	return path;
 }
 
 /* Return: 1 if PM is required, 0 if skip, or a negative error */
-- 
2.34.1

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The 'scheduling while atomic' bug remains unfixed in `coresight_put_percpu_source_ref()`, which can still trigger a system panic on PREEMPT_RT for other callers.
--

--- Patch [1]: [PATCH v4] coresight: Fix scheduling while atomic in coresight_cpu_pm_notify() ---
commit ced604f31de6d94adb2f729f01f491fe1766f6d1
Author: Mohamed Ayman <mohamedaymanworkspace@gmail.com>

coresight: Fix scheduling while atomic in coresight_cpu_pm_notify()

This commit addresses a "scheduling while atomic" bug on PREEMPT_RT in the
PM notifier path. It removes the get/put kobject reference dance, and instead
reads the per-cpu source pointer directly under the coresight_dev_lock.

> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
> index 6d65c43d574fd..9461fac9f1a3d 100644
> --- a/drivers/hwtracing/coresight/coresight-core.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -1850,16 +1850,13 @@ static void coresight_release_device_list(void)
>  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);

[Severity: High]
This is a pre-existing issue, but while this patch avoids the bug in this
specific PM notifier path, does coresight_put_percpu_source_ref() still
contain the exact same "scheduling while atomic" vulnerability for other
callers?

Looking at coresight_put_percpu_source_ref() in
drivers/hwtracing/coresight/coresight-core.c:

    guard(raw_spinlock_irqsave)(&coresight_dev_lock);

    /*
     * TODO: coresight_device_release() is invoked to release resources when
     * the device's refcount reaches zero. It then calls free_percpu(),
     * which acquires pcpu_lock — a sleepable lock when PREEMPT_RT is
     * enabled. Since the raw spinlock coresight_dev_lock is held, this can
     * lead to a potential "scheduling while atomic" issue.
     */
    put_device(&csdev->dev);

If put_device() drops the final reference concurrently with device
unregistration, it synchronously triggers the release function
coresight_device_release(). This cascade eventually calls free_percpu(),
which on PREEMPT_RT attempts to acquire the sleepable pcpu_lock.

Because coresight_put_percpu_source_ref() holds coresight_dev_lock (a raw
spinlock) via the guard during the put_device() call, could acquiring the
sleeping lock still cause a kernel panic if other callers hit this race?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722043023.6978-1-mohamedaymanworkspace@gmail.com?part=1