Re: [PATCH] ufs: core: Fix an error handler crash

[Nitin Rawat <nitin.rawat@oss.qualcomm.com>]

On 12/4/2025 10:34 PM, Bart Van Assche wrote:
> The UFS error handler may be activated before SCSI scanning has started and
> hence before hba->ufs_device_wlun has been set. Check the
> hba->ufs_device_wlun pointer before using it.
> 
> Cc: Peter Wang <peter.wang@mediatek.com>
> Cc: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
> Fixes: e23ef4f22db3 ("scsi: ufs: core: Fix error handler host_sem issue")
> Fixes: f966e02ae521 ("scsi: ufs: core: Fix runtime suspend error deadlock")
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
>   drivers/ufs/core/ufshcd.c | 25 ++++++++++++++-----------
>   1 file changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index b834b9635062..80c0b49f30b0 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -6698,19 +6698,22 @@ static void ufshcd_err_handler(struct work_struct *work)
>   		 hba->saved_uic_err, hba->force_reset,
>   		 ufshcd_is_link_broken(hba) ? "; link is broken" : "");
>   
> -	/*
> -	 * Use ufshcd_rpm_get_noresume() here to safely perform link recovery
> -	 * even if an error occurs during runtime suspend or runtime resume.
> -	 * This avoids potential deadlocks that could happen if we tried to
> -	 * resume the device while a PM operation is already in progress.
> -	 */
> -	ufshcd_rpm_get_noresume(hba);
> -	if (hba->pm_op_in_progress) {
> -		ufshcd_link_recovery(hba);
> +	if (hba->ufs_device_wlun) {
> +		/*
> +		 * Use ufshcd_rpm_get_noresume() here to safely perform link
> +		 * recovery even if an error occurs during runtime suspend or
> +		 * runtime resume. This avoids potential deadlocks that could
> +		 * happen if we tried to resume the device while a PM operation
> +		 * is already in progress.
> +		 */
> +		ufshcd_rpm_get_noresume(hba);
> +		if (hba->pm_op_in_progress) {
> +			ufshcd_link_recovery(hba);
> +			ufshcd_rpm_put(hba);
> +			return;
> +		}
>   		ufshcd_rpm_put(hba);
> -		return;
>   	}
> -	ufshcd_rpm_put(hba);
>   
>   	down(&hba->host_sem);
>   	spin_lock_irqsave(hba->host->host_lock, flags);


Hi Bart,

It seems you missed sending the below patch. Both patches are required 
to address the issue (hang and clock scaling errors), except for the UIC 
error, which still needs to be root-caused


 > diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
 > index 1b3fe1d8655e..fd0b6b620b53 100644
 > --- a/drivers/ufs/core/ufshcd.c
 > +++ b/drivers/ufs/core/ufshcd.c
 > @@ -1455,15 +1455,14 @@ static int ufshcd_clock_scaling_prepare(struct
 > ufs_hba *hba, u64 timeout_us)
 >   static void ufshcd_clock_scaling_unprepare(struct ufs_hba *hba, int 
err)
 >   {
 >         up_write(&hba->clk_scaling_lock);
 > -
 > +       mutex_unlock(&hba->wb_mutex);
 > +       blk_mq_unquiesce_tagset(&hba->host->tag_set);
 > +       mutex_unlock(&hba->host->scan_mutex);
 > +
 >         /* Enable Write Booster if current gear requires it else 
disable it */
 >         if (ufshcd_enable_wb_if_scaling_up(hba) && !err)
 >                 ufshcd_wb_toggle(hba, hba->pwr_info.gear_rx >=
 > hba->clk_scaling.wb_gear);
 >
 > -       mutex_unlock(&hba->wb_mutex);
 > -
 > -       blk_mq_unquiesce_tagset(&hba->host->tag_set);
 > -       mutex_unlock(&hba->host->scan_mutex);
 >         ufshcd_release(hba);
 >   }


Thanks,
Nitin