Hello Dexuan, On Fri, Apr 10, 2020 at 1:44 PM Dexuan Cui <decui@xxxxxxxxxxxxx> wrote: > > Hi all, > Can you please recommend the standard way to prevent the upper layer SCSI > driver from submitting new I/O requests when the system is doing hibernation? > > Actually I already asked the question on 5/30 last year: > https://marc.info/?l=linux-scsi&m=155918927116283&w=2 > and I thought all the sdevs are suspended and resumed automatically in > drivers/scsi/scsi_pm.c, and the low level SCSI adapter driver (i.e. hv_storvsc) > only needs to suspend/resume the state of the adapter itself. However, it looks > this is not true, because today I got such a panic in a v5.6 Linux VM running on > Hyper-V: the 'suspend' part of the hibernation process finished without any > issue, but when the VM was trying to resume back from the 'new' kernel to the > 'old' kernel, these events happened: > > 1. the new kernel loaded the saved state from disk to memory. > > 2. the new kernel quiesced the devices, including the SCSI DVD device > controlled by the hv_storvsc low level SCSI driver, i.e. > drivers/scsi/storvsc_drv.c: storvsc_suspend() was called and the related vmbus > ringbuffer was freed. > > 3. However, disk_events_workfn() -> ... -> cdrom_check_events() -> ... > -> scsi_queue_rq() -> ... -> storvsc_queuecommand() was still trying to > submit I/O commands to the freed vmbus ringbuffer, and as a result, a NULL > pointer dereference panic happened. Last time I replied to you in above link: "scsi_device_quiesce() has been called by scsi_dev_type_suspend() to prevent any non-pm request from entering queue." That meant no any normal FS request can enter scsi queue after suspend, however request with BLK_MQ_REQ_PREEMPT is still allowed to be queued to LLD after suspend. So you can't free related vmbus ringbuffer cause BLK_MQ_REQ_PREEMPT request is still to be handled. Thanks, Ming Lei
