runner: don't drop iscsi connection on lock fence errors

Don't escalate to dropping the iscsi connection if the lock is taken
from us. The initiator is most likely doing it's initialization and so
the lock is bouncing between paths during the device probe stage.

Signed-off-by: Mike Christie <mchristi@redhat.com>

tcmur_device.c

@@ -386,16 +386,15 @@ int tcmu_acquire_dev_lock(struct tcmu_device *dev, bool is_sync,
 			retries++;
 			goto retry;
 		}
+		/*
+		 * If we can't unfence ourself the lock is probably bouncing
+		 * due to path initialization. Allow the other node to hold the
+		 * lock for now, and the initiator will drive retries.
+		 */
 	}
 
 drop_conn:
-	/*
-	 * If we cannot unfence ourself or we cannot reach the backend,
-	 * disable the tpg until we can reopen the device. The initiator
-	 * can try another path while we try to fix things up in the
-	 * background.
-	 */
-	if (ret == TCMU_STS_TIMEOUT || ret == TCMU_STS_FENCED) {
+	if (ret == TCMU_STS_TIMEOUT) {
 		tcmu_dev_dbg(dev, "Fail handler device connection.\n");
 		tcmu_notify_conn_lost(dev);
 	}