mbox series

[0/9] Rework runtime suspend and SCSI domain validation

Message ID 20200906012219.17893-1-bvanassche@acm.org
Headers show
Series Rework runtime suspend and SCSI domain validation | expand

Message

Bart Van Assche Sept. 6, 2020, 1:22 a.m. UTC
Hi Jens,

The SCSI runtime suspend and domain validation mechanisms both use
scsi_device_quiesce(). scsi_device_quiesce() restricts blk_queue_enter() to
BLK_MQ_REQ_PREEMPT requests. There is a conflict between the requirements
of runtime suspend and SCSI domain validation: no requests must be sent to
runtime suspended devices that are in the state RPM_SUSPENDED while
BLK_MQ_REQ_PREEMPT requests must be processed during SCSI domain
validation. This conflict is resolved by reworking the SCSI domain
validation implementation.

Hybernation and runtime suspend have been retested but SCSI domain
validation not yet.

Please consider this patch series for kernel v5.10.

Thanks,

Bart.

Alan Stern (1):
  block: Do not accept any requests while suspended

Bart Van Assche (8):
  block: Fix a race in the runtime power management code
  ide: Do not set the RQF_PREEMPT flag for sense requests
  scsi: Pass a request queue pointer to __scsi_execute()
  scsi: Rework scsi_mq_alloc_queue()
  scsi: Do not wait for a request in scsi_eh_lock_door()
  scsi_transport_spi: Make spi_execute() accept a request queue pointer
  scsi_transport_spi: Freeze request queues instead of quiescing
  block, scsi, ide: Only process PM requests if rpm_status != RPM_ACTIVE

 block/blk-core.c                  |  12 +--
 block/blk-mq-debugfs.c            |   1 -
 block/blk-mq.c                    |   4 +-
 block/blk-pm.c                    |  15 ++--
 block/blk-pm.h                    |  14 +--
 drivers/ide/ide-atapi.c           |   1 -
 drivers/ide/ide-io.c              |   3 +-
 drivers/ide/ide-pm.c              |   2 +-
 drivers/scsi/scsi_error.c         |   3 +-
 drivers/scsi/scsi_lib.c           |  73 ++++++++--------
 drivers/scsi/scsi_priv.h          |   2 +
 drivers/scsi/scsi_transport_spi.c | 139 +++++++++++++++++-------------
 include/linux/blk-mq.h            |   4 +-
 include/linux/blkdev.h            |   6 +-
 include/scsi/scsi_device.h        |  14 ++-
 15 files changed, 158 insertions(+), 135 deletions(-)

Comments

Bart Van Assche Sept. 19, 2020, 3:45 a.m. UTC | #1
On 2020-09-05 18:22, Bart Van Assche wrote:
> The SCSI runtime suspend and domain validation mechanisms both use

> scsi_device_quiesce(). scsi_device_quiesce() restricts blk_queue_enter() to

> BLK_MQ_REQ_PREEMPT requests. There is a conflict between the requirements

> of runtime suspend and SCSI domain validation: no requests must be sent to

> runtime suspended devices that are in the state RPM_SUSPENDED while

> BLK_MQ_REQ_PREEMPT requests must be processed during SCSI domain

> validation. This conflict is resolved by reworking the SCSI domain

> validation implementation.

> 

> Hybernation and runtime suspend have been retested but SCSI domain

> validation not yet.


Hi Martin and James,

Please advise how to proceed with this patch series. This patch series
includes an important fix for runtime power management. Unfortunately
the only way to fix runtime powermanagement is by reworking SPI DV and
I don't have access to a setup on which I can test the SPI DV changes.

Thanks,

Bart.
Hannes Reinecke Sept. 21, 2020, 6 a.m. UTC | #2
On 9/19/20 5:45 AM, Bart Van Assche wrote:
> On 2020-09-05 18:22, Bart Van Assche wrote:

>> The SCSI runtime suspend and domain validation mechanisms both use

>> scsi_device_quiesce(). scsi_device_quiesce() restricts blk_queue_enter() to

>> BLK_MQ_REQ_PREEMPT requests. There is a conflict between the requirements

>> of runtime suspend and SCSI domain validation: no requests must be sent to

>> runtime suspended devices that are in the state RPM_SUSPENDED while

>> BLK_MQ_REQ_PREEMPT requests must be processed during SCSI domain

>> validation. This conflict is resolved by reworking the SCSI domain

>> validation implementation.

>>

>> Hybernation and runtime suspend have been retested but SCSI domain

>> validation not yet.

> 

> Hi Martin and James,

> 

> Please advise how to proceed with this patch series. This patch series

> includes an important fix for runtime power management. Unfortunately

> the only way to fix runtime powermanagement is by reworking SPI DV and

> I don't have access to a setup on which I can test the SPI DV changes.

> 

I'll check if I can resurrect my setup.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
Martin Kepplinger Sept. 29, 2020, 12:33 p.m. UTC | #3
On 19.09.20 05:45, Bart Van Assche wrote:
> On 2020-09-05 18:22, Bart Van Assche wrote:

>> The SCSI runtime suspend and domain validation mechanisms both use

>> scsi_device_quiesce(). scsi_device_quiesce() restricts blk_queue_enter() to

>> BLK_MQ_REQ_PREEMPT requests. There is a conflict between the requirements

>> of runtime suspend and SCSI domain validation: no requests must be sent to

>> runtime suspended devices that are in the state RPM_SUSPENDED while

>> BLK_MQ_REQ_PREEMPT requests must be processed during SCSI domain

>> validation. This conflict is resolved by reworking the SCSI domain

>> validation implementation.

>>

>> Hybernation and runtime suspend have been retested but SCSI domain

>> validation not yet.

> 

> Hi Martin and James,

> 

> Please advise how to proceed with this patch series. This patch series

> includes an important fix for runtime power management. Unfortunately

> the only way to fix runtime powermanagement is by reworking SPI DV and

> I don't have access to a setup on which I can test the SPI DV changes.

> 

> Thanks,

> 

> Bart.

> 


I only have my setup: SD cardreader connected via USB. I run this series
which fixes runtime PM in the block layer for me.

Sidenote: I need the following hack for my particular device too:
https://lore.kernel.org/linux-scsi/20200824190400.12339-1-martin.kepplinger@puri.sm/

I hope someone else can test the rest for us!

thanks for working on this,

                                martin
Martin K. Petersen Sept. 30, 2020, 2:47 a.m. UTC | #4
Hi Hannes,

> I'll check if I can resurrect my setup.


I'm afraid I don't have any SPI stuff to test with and it would be good
to get at least a basic smoke test performed on this series. So if you
have a setup to try it on that would be much appreciated.

Thanks!

-- 
Martin K. Petersen	Oracle Linux Engineering