On Mon, 7 Sep 2015, Xue, Ken wrote:
> Hi Alan and James,
> I found a bug about sr device runtime suspend & resume which is introduced by
> your patch about fixing NULL pointer dereference in runtime PM.
> You know that sr device only has runtime suspend routine but doesn't have
> resume routine.
> After your patch, blk_ *_ runtime_suspend will be called when runtime
> suspend. But blk_ *_ runtime_resume cannot be called when resume.
> So, sr device cannot work correctly after 1st runtime suspend.
Argh. Things just get more and more complicated...
> I want to make a dummy runtime resume routine in sr.c for fixing this runtime
> issue of sr device.
> If you guys think a dummy runtime routine for resume is acceptable, I can
> submit patch later.
A dummy routine isn't the greatest solution. Eventually someone will
see it, wonder why it's there, and remove it.
The real issue we need to address here is whether the driver has asked
for request-queue-oriented runtime PM by calling blk_pm_runtime_init().
If it hasn't then we need to skip at least the calls to
blk_{pre|post}_runtime_{suspend|resume}.
The patch I wrote uses the existence of runtime-PM callbacks as an
indicator for this, but evidently it isn't adequate. A more direct
approach would be to test whether sdev->request_queue->dev is non-NULL,
but this would be a layering violation.
Should we add a SCSI-level flag to indicate that blk_pm_runtime_init()
has been called?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
