On Wed, 2017-09-27 at 19:00 +0800, Ming Lei wrote: > With current linus tree, SCSI I/O is prevented from being dispatch to > device during suspend by SCSI quiesce, and will be dispatched again > in resume. With Safe SCSI quiesce[1], any underlying IO request will > stop at blk_queue_enter() during suspend, and restart from there during > resume. > > For other non-SCSI driver, their .suspend/.resume often > handles I/O in similar way, for example, NVMe queue will > be frozen in .suspend, and unfreeze in .resume. > > So could you explain a bit which kind of bug this patch fixes?
It seems like you do not fully understand the motivation behind quiescing and resuming I/O from inside the SCSI and NVMe freeze and thaw power management callbacks. Hibernation can only work reliably if no I/O is submitted after creation of the hibernation image has been started. If any I/O is submitted that is not related to the hibernation process itself by any driver after user space processes and kernel threads have been frozen then that's a *bug* in the component that submitted the I/O. The freezing and suspending of I/O from inside the SCSI and NVMe drivers is a *workaround* for these bugs but is not a full solution. Before the hibernation image is written to disk I/O is resumed and the I/O requests that got deferred will be executed at that time. In other words, suspending and resuming I/O from inside the SCSI and NVMe drivers is a workaround and not a full solution. The following quote from Documentation/power/swsusp.txt illustrates this: * BIG FAT WARNING ********************************************************* * * If you touch anything on disk between suspend and resume... * ...kiss your data goodbye. Bart.
