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

On 2026-07-17 00:41:54 [+0300], Mohamed Ayman wrote:
> Dropping the last reference to a coresight_device can trigger a kernel
> panic on PREEMPT_RT builds due to a "scheduling while atomic" violation.

It is not a panic, it is a warning. A panic is after panic() is invoked.
[ Or a warning with /proc/sys/kernel/panic_on_warn=1 but in this case I
wouldn't count this a panic but as warning followed by consequences of
your own action ]

> 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 rt-mutex.

Again, spinlock_t which becomes a sleeping lock on PREEMPT_RT.

> 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.

Right.

Reviewed-by: Sebastian Andrzej Siewior <[email protected]>

> Suggested-by: Sebastian Andrzej Siewior <[email protected]>
> Signed-off-by: Mohamed Ayman <[email protected]>

There is coresight_put_percpu_source_ref() with holds coresight_dev_lock
during a put_cpu. I don't know why the lock is held, it is not obvious
to me. But it will lead to a similar problem if the put actually invokes
the release callback.

Sebastian