RE: [PATCH] scsi: core: Allow the state change from SDEV_QUIESCE to SDEV_BLOCK

[Dexuan Cui]

> From: Ming Lei <ming.lei@xxxxxxxxxx>
> Sent: Friday, April 17, 2020 7:42 PM
> To: Dexuan Cui <decui@xxxxxxxxxxxxx>
> Cc: jejb@xxxxxxxxxxxxx; martin.petersen@xxxxxxxxxx;
> linux-scsi@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; hch@xxxxxx;
> bvanassche@xxxxxxx; hare@xxxxxxx; Michael Kelley
> <mikelley@xxxxxxxxxxxxx>; Long Li <longli@xxxxxxxxxxxxx>
> Subject: Re: [PATCH] scsi: core: Allow the state change from SDEV_QUIESCE to
> SDEV_BLOCK
> 
> On Fri, Apr 17, 2020 at 05:40:45PM -0700, Dexuan Cui wrote:
> > The APIs scsi_host_block()/scsi_host_unblock() are recently added by:
> > 2bb955840c1d ("scsi: core: add scsi_host_(block,unblock) helper function")
> > and so far the APIs are only used by:
> > 3d3ca53b1639 ("scsi: aacraid: use scsi_host_(block,unblock) to block I/O")
> >
> > However, from reading the code, I think the APIs don't really work for
> > aacraid, because, in the resume path of hibernation, when aac_suspend() ->
> > scsi_host_block() is called, scsi_device_quiesce() has set the state to
> > SDEV_QUIESCE, so aac_suspend() -> scsi_host_block() returns -EINVAL.
> >
> > Fix the issue by allowing the state change.
> >
> > Fixes: 2bb955840c1d ("scsi: core: add scsi_host_(block,unblock) helper
> function")
> > Signed-off-by: Dexuan Cui <decui@xxxxxxxxxxxxx>
> > ---
> >  drivers/scsi/scsi_lib.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > index 47835c4b4ee0..06c260f6cdae 100644
> > --- a/drivers/scsi/scsi_lib.c
> > +++ b/drivers/scsi/scsi_lib.c
> > @@ -2284,6 +2284,7 @@ scsi_device_set_state(struct scsi_device *sdev,
> enum scsi_device_state state)
> >  		switch (oldstate) {
> >  		case SDEV_RUNNING:
> >  		case SDEV_CREATED_BLOCK:
> > +		case SDEV_QUIESCE:
> >  		case SDEV_OFFLINE:
> >  			break;
> >  		default:
> 
> Looks reasonable because SDEV_BLOCK is one more strict state than
> QEIESCE, so:

Thanks, Ming!

> Reviewed-by: Ming Lei <ming.lei@xxxxxxxxx>
> 
> Thanks,
> Ming

There should be a small typo: s/redha/redhat :-)

Thanks,
-- Dexuan