From: <gregkh@linuxfoundation.org>
To: sagig@mellanox.com, gregkh@linuxfoundation.org,
jennyf@mellanox.com, nab@linux-iscsi.org
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "iser-target: release stale iser connections" has been added to the 3.14-stable tree
Date: Thu, 30 Jul 2015 17:59:15 -0700 [thread overview]
Message-ID: <1438304355146241@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
iser-target: release stale iser connections
to the 3.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
iser-target-release-stale-iser-connections.patch
and it can be found in the queue-3.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 2f1b6b7d9a815f341b18dfd26a363f37d4d3c96a Mon Sep 17 00:00:00 2001
From: Sagi Grimberg <sagig@mellanox.com>
Date: Thu, 4 Jun 2015 19:49:20 +0300
Subject: iser-target: release stale iser connections
From: Sagi Grimberg <sagig@mellanox.com>
commit 2f1b6b7d9a815f341b18dfd26a363f37d4d3c96a upstream.
When receiving a new iser connect request we serialize
the pending requests by adding the newly created iser connection
to the np accept list and let the login thread process the connect
request one by one (np_accept_wait).
In case we received a disconnect request before the iser_conn
has begun processing (still linked in np_accept_list) we should
detach it from the list and clean it up and not have the login
thread process a stale connection. We do it only when the connection
state is not already terminating (initiator driven disconnect) as
this might lead us to access np_accept_mutex after the np was released
in live shutdown scenarios.
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Jenny Falkovich <jennyf@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/isert/ib_isert.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/ulp/isert/ib_isert.c
+++ b/drivers/infiniband/ulp/isert/ib_isert.c
@@ -59,6 +59,8 @@ static int
isert_rdma_accept(struct isert_conn *isert_conn);
struct rdma_cm_id *isert_setup_id(struct isert_np *isert_np);
+static void isert_release_work(struct work_struct *work);
+
static void
isert_qp_event_callback(struct ib_event *e, void *context)
{
@@ -534,6 +536,7 @@ isert_connect_request(struct rdma_cm_id
mutex_init(&isert_conn->conn_mutex);
spin_lock_init(&isert_conn->conn_lock);
INIT_LIST_HEAD(&isert_conn->conn_fr_pool);
+ INIT_WORK(&isert_conn->release_work, isert_release_work);
isert_conn->conn_cm_id = cma_id;
isert_conn->responder_resources = event->param.conn.responder_resources;
@@ -800,6 +803,7 @@ isert_disconnected_handler(struct rdma_c
{
struct isert_np *isert_np = cma_id->context;
struct isert_conn *isert_conn;
+ bool terminating = false;
if (isert_np->np_cm_id == cma_id)
return isert_np_cma_handler(cma_id->context, event);
@@ -807,12 +811,25 @@ isert_disconnected_handler(struct rdma_c
isert_conn = cma_id->qp->qp_context;
mutex_lock(&isert_conn->conn_mutex);
+ terminating = (isert_conn->state == ISER_CONN_TERMINATING);
isert_conn_terminate(isert_conn);
mutex_unlock(&isert_conn->conn_mutex);
pr_info("conn %p completing conn_wait\n", isert_conn);
complete(&isert_conn->conn_wait);
+ if (terminating)
+ goto out;
+
+ mutex_lock(&isert_np->np_accept_mutex);
+ if (!list_empty(&isert_conn->conn_accept_node)) {
+ list_del_init(&isert_conn->conn_accept_node);
+ isert_put_conn(isert_conn);
+ queue_work(isert_release_wq, &isert_conn->release_work);
+ }
+ mutex_unlock(&isert_np->np_accept_mutex);
+
+out:
return 0;
}
@@ -2948,7 +2965,6 @@ static void isert_wait_conn(struct iscsi
wait_for_completion(&isert_conn->conn_wait_comp_err);
- INIT_WORK(&isert_conn->release_work, isert_release_work);
queue_work(isert_release_wq, &isert_conn->release_work);
}
Patches currently in stable-queue which might be from sagig@mellanox.com are
queue-3.14/iser-target-fix-possible-deadlock-in-rdma_cm-connection-error.patch
queue-3.14/scsi_transport_srp-introduce-srp_wait_for_queuecommand.patch
queue-3.14/iser-target-release-stale-iser-connections.patch
queue-3.14/iscsi-target-convert-iscsi_thread_set-usage-to-kthread.h.patch
queue-3.14/scsi_transport_srp-fix-a-race-condition.patch
reply other threads:[~2015-07-31 0:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1438304355146241@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=jennyf@mellanox.com \
--cc=nab@linux-iscsi.org \
--cc=sagig@mellanox.com \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).