Re: [PATCH v1] ufs: core: Fix runtime suspend error deadlock

Bart Van Assche
2025-09-23T16:07:39Z

On 9/23/25 1:20 AM, peter.wang@mediatek.com wrote:
> From: Peter Wang <peter.wang@mediatek.com>
>
> Resolve the deadlock issue during runtime suspend when an
> error triggers the error handler. Prevent the deadlock
> by checking pm_op_in_progress and performing a quick recovery.
> This approach ensures that the error handler does not wait
> indefinitely for runtime PM to resume, allowing runtime
> suspend to proceed smoothly.
>
> Signed-off-by: Peter Wang <peter.wang@mediatek.com>
> Suggested-by: Bart Van Assche <bvanassche@acm.org>
> Tested-by: Bart Van Assche <bvanassche@acm.org>
> ---
> drivers/ufs/core/ufshcd.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 88a0e9289ca6..0735bd5df1cc 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -6681,6 +6681,11 @@ static void ufshcd_err_handler(struct work_struct *work)
> }
> spin_unlock_irqrestore(hba->host->host_lock, flags);
>
> + if (hba->pm_op_in_progress) {
> + ufshcd_link_recovery(hba);
> + return;
> + }
> +
> ufshcd_err_handling_prepare(hba);
>
> spin_lock_irqsave(hba->host->host_lock, flags);

Does this patch introduce a race condition? Can a power management
operation start after hba->pm_op_in_progress has been tested and before
ufshcd_err_handling_prepare() is called? Should the added code perhaps
be surrounded with ufshcd_rpm_get_noresume() and ufshcd_rpm_put()?

Thanks,

Bart.