[PATCH 14/15] libiscsi: drop back_lock from xmit path

[Mike Christie <michael.christie@oracle.com>]

We have a proper refcount on the task so if we get a rsp while R2Ts are
queued then we will not crash. We only need to check if a rsp has been
processed and if we race it's ok since with a bad target we could get
this rsp at any time like after dropping the lock and starting to send
data so the lock use doesn't matter.

This patch just drops the lock since we will eventually either see
the updated state or we will send all the data and free the task.
I'm not 100% sure though and am thinking we might want to use READ/
WRITE_ONCE or use a barrier?

Signed-off-by: Mike Christie <michael.christie@oracle.com>
---
 drivers/scsi/libiscsi.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 0643156..e020fba 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -1529,8 +1529,6 @@ static int iscsi_xmit_task(struct iscsi_conn *conn, bool has_extra_ref)
 		/* done with this task */
 		task->last_xfer = jiffies;
 	}
-	/* regular RX path uses back_lock */
-	spin_lock(&conn->session->back_lock);
 	if (rc && task->state == ISCSI_TASK_RUNNING) {
 		/*
 		 * get an extra ref that is released next time we access it
@@ -1539,7 +1537,6 @@ static int iscsi_xmit_task(struct iscsi_conn *conn, bool has_extra_ref)
 		iscsi_get_task(task);
 		conn->task = task;
 	}
-	spin_unlock(&conn->session->back_lock);
 
 put_task:
 	iscsi_put_task(task);
-- 
1.8.3.1