Re: [PATCH v4] coresight: Fix scheduling while atomic in coresight_cpu_pm_notify()

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 <[email protected]>

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/[email protected]?part=1