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. Bart.
