Re: [PATCH] scsi: core: ufs: Fix a hang in the error handler

["Peter Wang (王信友)" <peter.wang@mediatek.com>]

On Fri, 2025-05-23 at 13:14 -0700, Bart Van Assche wrote:
> 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> From: Sanjeev Yadav <sanjeev.y@mediatek.com>
> 
> ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter
> function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because
> resuming involves submitting a SCSI command and ufshcd_queuecommand()
> returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix
> this hang by setting UFSHCD_EH_IN_PROGRESS after
> ufshcd_rpm_get_sync() has been called instead of before.
> 
> Backtrace:
> __switch_to+0x174/0x338
> __schedule+0x600/0x9e4
> schedule+0x7c/0xe8
> schedule_timeout+0xa4/0x1c8
> io_schedule_timeout+0x48/0x70
> wait_for_common_io+0xa8/0x160 //waiting on START_STOP
> wait_for_completion_io_timeout+0x10/0x20
> blk_execute_rq+0xe4/0x1e4
> scsi_execute_cmd+0x108/0x244
> ufshcd_set_dev_pwr_mode+0xe8/0x250
> __ufshcd_wl_resume+0x94/0x354
> ufshcd_wl_runtime_resume+0x3c/0x174
> scsi_runtime_resume+0x64/0xa4
> rpm_resume+0x15c/0xa1c
> __pm_runtime_resume+0x4c/0x90 // Runtime resume ongoing
> ufshcd_err_handler+0x1a0/0xd08
> process_one_work+0x174/0x808
> worker_thread+0x15c/0x490
> kthread+0xf4/0x1ec
> ret_from_fork+0x10/0x20
> 
> Signed-off-by: Sanjeev Yadav <sanjeev.y@mediatek.com>
> [ bvanassche: rewrote patch description ]
> Fixes: 62694735ca95 ("[SCSI] ufs: Add runtime PM support for UFS host
> controller driver")
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>


Hi Bart,

I'm a bit curious why the ufshcd_err_handler was triggered?
Because during the runtime suspend/resume process, if there 
are any errors, it should use ufshcd_link_recovery directly?

Thanks.
Peter