Re: [PATCH] scsi: scsi_transport_srp: don't block target in SRP_PORT_LOST state

From: Laurence Oberman <loberman@redhat.com>
To: Bart Van Assche <bvanassche@acm.org>,
	mwilck@suse.com,
	"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Hannes Reinecke <hare@suse.de>,
	linux-scsi@vger.kernel.org,
	James Bottomley <jejb@linux.vnet.ibm.com>
Subject: Re: [PATCH] scsi: scsi_transport_srp: don't block target in SRP_PORT_LOST state
Date: Fri, 02 Apr 2021 16:15:27 -0400	[thread overview]
Message-ID: <881ff1e6ac12fc73d10d0119dfa36b1ed3d71a21.camel@redhat.com> (raw)
In-Reply-To: <af2a5e04-8ed8-f33c-68f9-84483c18e2d5@acm.org>

On Fri, 2021-04-02 at 12:38 -0700, Bart Van Assche wrote:
> On 4/1/21 2:11 AM, mwilck@suse.com wrote:
> > rport_dev_loss_timedout() sets the rport state to SRP_PORT_LOST and
> > the SCSI target state to SDEV_TRANSPORT_OFFLINE. If this races with
> > srp_reconnect_work(), a warning is printed:
> 
> Reviewed-by: Bart Van Assche <bvanassche@acm.org>
> 

Indeed I have seen this while running rapid resets in my lab. Was not
sure if it was something I was doing or a real bug.

For example this script will bring it out if I lower the delay
#!/bin/bash
#on ibclient server in /sys/class/srp_remote_ports, using echo 1 >
delete for the particular port will simulate a port reset.

#/sys/class/srp_remote_ports
#[root@ibclient srp_remote_ports]# ls
#port-1:1  port-2:1
for d in /sys/class/srp_remote_ports/*
do
	echo 1 > $d/delete
sleep 60
done

Looks correct, and anyway Bart agrees so:

Reviewed-by:
Laurence Oberman <loberman@redhat.com>