Re: [PATCH v1 1/1] scsi: Synchronize request queue PM status only on successful resume

[Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>]

On Thu, 2019-01-03 at 14:38 +0800, Stanley Chu wrote:
> We found NULL sdev->request_queue->dev may be dereferenced during below
> system resume flow,
> 
> scsi_bus_resume_common()
>  => async_schedule_domain(async_sdev_resume)
> 
> And then async_sdev_resume() is invoked asynchronously,
>  
> async_sdev_resume()
>  => scsi_dev_type_resume(dev, do_scsi_resume)
>   => blk_set_runtime_active(sdev->request_queue)
> 
> If a SCSI device does not have upper layer driver (like SCSI disk), it
> may not be applied blk_pm_runtime_init() invoked by sd_probe() while
> this SCSI device is added.
> 
> For example, some SCSI devices (like UFS Boot W-LUN) are added
> explicitly in __scsi_add_device() by ufshcd_scsi_add_wlus() first and
> thus sd_probe() for them is skipped because they are already visible.
> 
> For those SCSI devices, null sdev->request_queue->dev will be
> dereferenced in blk_set_runtime_active() during above system resume
> flow, therefore we add a null pointer checking for this case.
> 
> The same issue also happens on those SCSI devices before this patch as
> below system resume flow while devices are already runtime-suspended.
> 
> scsi_bus_resume_common()
>  => blk_set_runtime_active(to_scsi_device(dev)->request_queue)

Hi Stanley,

Thanks, this is helpful information. If you would have to repost your
patch please add a comment that refers to the __scsi_add_device() calls
in the UFS driver.

Bart.