linux-kernel - omap_remoteproc: Deadlock due to runtime PM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <6460478.iFIW2sfyFC@nailgun>
Date: Wed, 08 Oct 2025 22:04:57 +0200
From: Richard Weinberger <richard@...ma-star.at>
To: linux-remoteproc@...r.kernel.org
Cc: andersson@...nel.org, mathieu.poirier@...aro.org, p.zabel@...gutronix.de,
 s-anna@...com, t-kristo@...com, afd@...com, linux-kernel@...r.kernel.org,
 upstream+rproc@...ma-star.at
Subject: omap_remoteproc: Deadlock due to runtime PM

Hi!

I'm seeing a reproducible deadlock in omap_remoteproc during system
reboot or shutdown while the remote processor is running.

The deadlock occurs as follows:
rproc_cdev_release() -> rproc_shutdown() -> mutex_lock_interruptible(&rproc->lock)
-> rproc_stop() -> omap_rproc_stop() -> pm_runtime_get_sync()

pm_runtime_get_sync() triggers omap_rproc_runtime_resume(),
which attempts to take rproc->lock again, leading to a deadlock.

In other words, rproc->lock is being used within the omap_remoteproc
runtime PM ops, which can conflict with other call paths that already
hold the same lock.

It was introduced with the following change:

commit 5f31b232c67434199558fd236e7644b432636b76
Author: Suman Anna <s-anna@...com>
Date:   Tue Mar 24 13:00:32 2020 +0200

    remoteproc/omap: Add support for runtime auto-suspend/resume

It seems the lock is taken in the PM ops likely because rproc->state 
is accessed, but perhaps this can be relaxed or refactored to avoid
the circular dependency.

Has anyone else encountered this issue,
or is there a known fix or approach to address it?

Thanks,
//richard