On Thu, 2019-01-03 at 14:38 +-0800, Stanley Chu wrote: +AD4 We found NULL sdev-+AD4-request+AF8-queue-+AD4-dev may be dereferenced during below +AD4 system resume flow, +AD4 +AD4 scsi+AF8-bus+AF8-resume+AF8-common() +AD4 +AD0APg async+AF8-schedule+AF8-domain(async+AF8-sdev+AF8-resume) +AD4 +AD4 And then async+AF8-sdev+AF8-resume() is invoked asynchronously, +AD4 +AD4 async+AF8-sdev+AF8-resume() +AD4 +AD0APg scsi+AF8-dev+AF8-type+AF8-resume(dev, do+AF8-scsi+AF8-resume) +AD4 +AD0APg blk+AF8-set+AF8-runtime+AF8-active(sdev-+AD4-request+AF8-queue) +AD4 +AD4 If a SCSI device does not have upper layer driver (like SCSI disk), it +AD4 may not be applied blk+AF8-pm+AF8-runtime+AF8-init() invoked by sd+AF8-probe() while +AD4 this SCSI device is added. +AD4 +AD4 For example, some SCSI devices (like UFS Boot W-LUN) are added +AD4 explicitly in +AF8AXw-scsi+AF8-add+AF8-device() by ufshcd+AF8-scsi+AF8-add+AF8-wlus() first and +AD4 thus sd+AF8-probe() for them is skipped because they are already visible. +AD4 +AD4 For those SCSI devices, null sdev-+AD4-request+AF8-queue-+AD4-dev will be +AD4 dereferenced in blk+AF8-set+AF8-runtime+AF8-active() during above system resume +AD4 flow, therefore we add a null pointer checking for this case. +AD4 +AD4 The same issue also happens on those SCSI devices before this patch as +AD4 below system resume flow while devices are already runtime-suspended. +AD4 +AD4 scsi+AF8-bus+AF8-resume+AF8-common() +AD4 +AD0APg blk+AF8-set+AF8-runtime+AF8-active(to+AF8-scsi+AF8-device(dev)-+AD4-request+AF8-queue) Hi Stanley, Thanks, this is helpful information. If you would have to repost your patch please add a comment that refers to the +AF8AXw-scsi+AF8-add+AF8-device() calls in the UFS driver. Bart.
