mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Or Gerlitz <ogerlitz@voltaire.com>
To: Sean Hefty <sean.hefty@intel.com>
Cc: linux-kernel@vger.kernel.org, openib-general@openib.org
Subject: Re: [openib-general] [PATCH 5/6] iser RDMA CM (CMA) and IB verbsinteraction
Date: Mon, 01 May 2006 16:02:13 +0300	[thread overview]
Message-ID: <445606D5.20907@voltaire.com> (raw)
In-Reply-To: <ORSMSX401EXUIEAOeIi0000001c@orsmsx401.amr.corp.intel.com>

Sean Hefty wrote:
>> +static void iser_disconnected_handler(struct rdma_cm_id *cma_id)
>> +{
>> +	struct iser_conn *ib_conn;
>> +
>> +	ib_conn = (struct iser_conn *)cma_id->context;
>> +	ib_conn->disc_evt_flag = 1;
>> +
>> +	/* If this event is unsolicited this means that the conn is being */
>> +	/* terminated asynchronously from the iSCSI layer's perspective.  */
>> +	if (atomic_read(&ib_conn->state) == ISER_CONN_PENDING) {
>> +		atomic_set(&ib_conn->state, ISER_CONN_DOWN);
>> +		wake_up_interruptible(&ib_conn->wait);
>> +	} else {
>> +		if (atomic_read(&ib_conn->state) == ISER_CONN_UP) {
>> +			atomic_set(&ib_conn->state, ISER_CONN_TERMINATING);
>> +			iscsi_conn_failure(ib_conn->iser_conn->iscsi_conn,
>> +						ISCSI_ERR_CONN_FAILED);
>> +		}
>> +		/* Complete the termination process if no posts are pending */
>> +		if ((atomic_read(&ib_conn->post_recv_buf_count) == 0) &&
>> +		    (atomic_read(&ib_conn->post_send_buf_count) == 0)) {
>> +			atomic_set(&ib_conn->state, ISER_CONN_DOWN);
>> +			wake_up_interruptible(&ib_conn->wait);
>> +		}
>> +	}

> Are there races here between reading ib_conn->state and setting it?  Could it
> have changed in between the atomic_read() and atomic_set()?

It seems that indeed a race is possible here, i am rethinking now on the 
implementation of the ib connection states moves, thanks for pointing this.

>> +	src = (struct sockaddr *)src_addr;
>> +	dst = (struct sockaddr *)dst_addr;
>> +	err = rdma_resolve_addr(ib_conn->cma_id, src, dst, 1000);
>> +	if (err) {
>> +		iser_err("rdma_resolve_addr failed: %d\n", err);
>> +		goto addr_failure;
>> +	}
>> +
>> +	if (!non_blocking) {
>> +		wait_event_interruptible(ib_conn->wait,
>> +			 atomic_read(&ib_conn->state) != ISER_CONN_PENDING);
>> +
>> +		if (atomic_read(&ib_conn->state) != ISER_CONN_UP) {
>> +			err =  -EIO;
>> +			goto connect_failure;
>> +		}
>> +	}
>> +
>> +	mutex_lock(&ig.connlist_mutex);
>> +	list_add(&ib_conn->conn_list, &ig.connlist);
>> +	mutex_unlock(&ig.connlist_mutex);

> Not sure if there's a race here or not, but rdma_resolve_addr() will result in a
> callback from a separate thread.  That callback could occur before the ib_conn
> is added to the ig.connlist.  Do you assume that ib_conn is in the connlist in
> any of the callbacks?

No, i don't assume this in the callbacks. ib_conn is inserted to the 
list in iser_connect and being lookup-ed in ep_poll, conn_bind and 
ep_disconnect where each subset of the latter three functions are 
serialized are iser_connect since they are called by the same user space 
process (iscsid, via iscsi netlink u/k IPC mechanism).

However, in a review i have made to fully answer your question i have 
found a possible double call to iser_conn_release where the fix below 
handles it.

------------------------------------------------------------------------
r6802 | ogerlitz | 2006-05-01 12:27:12 +0300 (Mon, 01 May 2006) | 5 lines

move the ib conn deletion from the global connlist to iser_conn_release,
fix ep_disconnect to call conn_terminate or conn_release but not both.

Signed-off-by: Or Gerlitz <ogerlitz@voltaire.com>

Index: iser_verbs.c
===================================================================
--- iser_verbs.c	(revision 6761)
+++ iser_verbs.c	(revision 6802)
@@ -301,10 +301,6 @@ void iser_conn_terminate(struct iser_con
  	wait_event_interruptible(ib_conn->wait,
  				 (atomic_read(&ib_conn->state) == ISER_CONN_DOWN));

-	mutex_lock(&ig.connlist_mutex);
-	list_del(&ib_conn->conn_list);
-	mutex_unlock(&ig.connlist_mutex);
-
  	iser_conn_release(ib_conn);
  }

@@ -463,6 +459,7 @@ int iser_conn_init(struct iser_conn **ib
  	atomic_set(&ib_conn->post_send_buf_count, 0);
  	INIT_WORK(&ib_conn->comperror_work, iser_comp_error_worker,
  		  ib_conn);
+	INIT_LIST_HEAD(&ib_conn->conn_list);

  	*ibconn = ib_conn;
  	return 0;
@@ -541,6 +538,10 @@ void iser_conn_release(struct iser_conn

  	BUG_ON(atomic_read(&ib_conn->state) != ISER_CONN_DOWN);

+	mutex_lock(&ig.connlist_mutex);
+	list_del(&ib_conn->conn_list);
+	mutex_unlock(&ig.connlist_mutex);
+
  	iser_free_ib_conn_res(ib_conn);
  	ib_conn->device = NULL;
  	/* on EVENT_ADDR_ERROR there's no device yet for this conn */
Index: iscsi_iser.c
===================================================================
--- iscsi_iser.c	(revision 6761)
+++ iscsi_iser.c	(revision 6802)
@@ -680,8 +680,8 @@ iscsi_iser_ep_disconnect(__u64 ep_handle

  	if (atomic_read(&ib_conn->state) == ISER_CONN_UP)
  		iser_conn_terminate(ib_conn);
-
-	iser_conn_release(ib_conn);
+	else
+		iser_conn_release(ib_conn);
  }

  static struct scsi_host_template iscsi_iser_sht = {





  parent reply	other threads:[~2006-05-01 13:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-27 12:30 [PATCH 0/6] iSER (iSCSI Extensions for RDMA) initiator Or Gerlitz
2006-04-27 12:30 ` [PATCH 1/6] iSER's Makefile and Kconfig Or Gerlitz
2006-04-27 12:31   ` [PATCH 2/6] iscsi_iser header file Or Gerlitz
2006-04-27 12:31     ` [PATCH 3/6] open iscsi iser transport provider code Or Gerlitz
2006-04-27 12:32       ` [PATCH 4/6] iser initiator Or Gerlitz
2006-04-27 12:32         ` [PATCH 5/6] iser RDMA CM (CMA) and IB verbs interaction Or Gerlitz
2006-04-27 12:33           ` [PATCH 6/6] iser handling of memory for RDMA Or Gerlitz
2006-04-28 23:05           ` [openib-general] [PATCH 5/6] iser RDMA CM (CMA) and IB verbsinteraction Sean Hefty
2006-04-30 12:30             ` Or Gerlitz
2006-05-01 13:02             ` Or Gerlitz [this message]
2006-05-04 13:00               ` [openib-general] [PATCH 5/6] iser RDMA CM (CMA) and IB verbs interaction Or Gerlitz
2006-05-04 13:06                 ` Or Gerlitz
2006-04-27 17:01       ` [PATCH 3/6] open iscsi iser transport provider code Stephen Hemminger
2006-04-27 16:58     ` [PATCH 2/6] iscsi_iser header file Stephen Hemminger
2006-04-27 12:40   ` [PATCH 1/6] iSER's Makefile and Kconfig Jan-Benedict Glaw
2006-04-27 12:44     ` Or Gerlitz
2006-05-01 18:32 ` [PATCH 0/6] iSER (iSCSI Extensions for RDMA) initiator Roland Dreier
2006-05-02  7:56   ` Or Gerlitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=445606D5.20907@voltaire.com \
    --to=ogerlitz@voltaire.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openib-general@openib.org \
    --cc=sean.hefty@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome