On 7/2/20 7:23 PM, Bart Van Assche wrote:
On 2020-07-02 08:14, Hannes Reinecke wrote:
On 7/2/20 4:34 PM, James Bottomley wrote:
On Thu, 2020-07-02 at 16:24 +0200, Hannes Reinecke wrote:
scsi_transport_srp.c will call scsi_target_block() repeatedly
without calling scsi_target_unblock() first.
So allow the idempotent state transition BLOCK -> BLOCK to avoid
a warning here.
That really doesn't sound like a good idea. Block and unblock should
be matched pairs and since you don't have a running->running transition
allowed this implies that srp calls block many times but unblock only
once. It really sounds like srp needs fixing.
That was what I was planning first, but then SRP has a weird mix of states, calling scsi_target_block()/scsi_target_unblock() on all sorts of places.
It is not clear to me how the SRP transport code could call
scsi_target_block() twice without calling scsi_target_unblock() in
between? All these calls are serialized by the rport mutex.
scsi_target_block() is called when the port state is changed to
SRP_RPORT_BLOCKED. scsi_target_unblock() is called when the port
state is changed into another state than SRP_RPORT_BLOCKED.
And it's called from srp_reconnect_rport() and __rport_fail_io_fast(),
so we have this call chain:
srp_reconnect_rport()
- scsi_target_block()
-> __rport_fail_io_fast()
- scsi_target_block()
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
