summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorSagi Grimberg <sagig@mellanox.com>2014-12-02 16:57:36 +0200
committerNicholas Bellinger <nab@linux-iscsi.org>2014-12-12 23:32:27 -0800
commit268e6811f5729fb9ce7415586bd992b504fe95a2 (patch)
tree5ee63f064d94f864cf1877ee6e6363ab8621d675
parent23a548ee656c8ba6da8cb2412070edcd62e2ac5d (diff)
downloadop-kernel-dev-268e6811f5729fb9ce7415586bd992b504fe95a2.zip
op-kernel-dev-268e6811f5729fb9ce7415586bd992b504fe95a2.tar.gz
iser-target: Work-around live target stack shutdown resource cleanup
Currently we have no way to tell that the target stack is in shutdown sequence. In case we have open connections, the initiator immediately attempts to reconnect in a DDOS attack style, so we may end up terminating the iser enabled network portal while it's np_accept_list still have pending connections. The workaround is simply release all the connections in the list. A proper fix will be to start shutdown sequence by shutting the network portal to avoid initiator immediate reconnect attempts. But the temporary work around seems to work at this point, so I think we can do this for now... Reported-by: Slava Shwartsman <valyushash@gmail.com> Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
-rw-r--r--drivers/infiniband/ulp/isert/ib_isert.c21
1 files changed, 21 insertions, 0 deletions
diff --git a/drivers/infiniband/ulp/isert/ib_isert.c b/drivers/infiniband/ulp/isert/ib_isert.c
index a6daabc..b88686e 100644
--- a/drivers/infiniband/ulp/isert/ib_isert.c
+++ b/drivers/infiniband/ulp/isert/ib_isert.c
@@ -3369,10 +3369,31 @@ static void
isert_free_np(struct iscsi_np *np)
{
struct isert_np *isert_np = (struct isert_np *)np->np_context;
+ struct isert_conn *isert_conn, *n;
if (isert_np->np_cm_id)
rdma_destroy_id(isert_np->np_cm_id);
+ /*
+ * FIXME: At this point we don't have a good way to insure
+ * that at this point we don't have hanging connections that
+ * completed RDMA establishment but didn't start iscsi login
+ * process. So work-around this by cleaning up what ever piled
+ * up in np_accept_list.
+ */
+ mutex_lock(&isert_np->np_accept_mutex);
+ if (!list_empty(&isert_np->np_accept_list)) {
+ pr_info("Still have isert connections, cleaning up...\n");
+ list_for_each_entry_safe(isert_conn, n,
+ &isert_np->np_accept_list,
+ conn_accept_node) {
+ pr_info("cleaning isert_conn %p state (%d)\n",
+ isert_conn, isert_conn->state);
+ isert_connect_release(isert_conn);
+ }
+ }
+ mutex_unlock(&isert_np->np_accept_mutex);
+
np->np_context = NULL;
kfree(isert_np);
}
OpenPOWER on IntegriCloud