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.
