All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.