From: "Steve Wise" <swise@opengridcomputing.com>
To: "'Sagi Grimberg'" <sagi@lightbits.io>,
"'Christoph Hellwig'" <hch@lst.de>, <axboe@kernel.dk>,
<keith.busch@intel.com>, <sean.hefty@intel.com>
Cc: <linux-nvme@lists.infradead.org>, <linux-block@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
"'Armen Baloyan'" <armenx.baloyan@intel.com>,
"'Jay Freyensee'" <james.p.freyensee@intel.com>,
"'Ming Lin'" <ming.l@ssi.samsung.com>,
<linux-rdma@vger.kernel.org>
Subject: RE: [PATCH 4/5] nvmet-rdma: add a NVMe over Fabrics RDMA target driver
Date: Tue, 14 Jun 2016 11:22:25 -0500 [thread overview]
Message-ID: <00f701d1c658$efd720d0$cf856270$@opengridcomputing.com> (raw)
In-Reply-To: <00f501d1c657$483a74e0$d8af5ea0$@opengridcomputing.com>
>
> Hey Sean,
>
> Am I correct here? IE: Is it ok for the rdma application to rdma_reject() and
> rmda_destroy_id() the CONNECT_REQUEST cm_id _inside_ its event handler as
> long
> as it returns 0?
>
> Thanks,
>
> Steve.
Looking at rdma_destroy_id(), I think it is invalid to call it from the event
handler:
void rdma_destroy_id(struct rdma_cm_id *id)
{
<snip>
/*
* Wait for any active callback to finish. New callbacks will find
* the id_priv state set to destroying and abort.
*/
mutex_lock(&id_priv->handler_mutex);
mutex_unlock(&id_priv->handler_mutex);
And indeed when I tried to destroy the CONNECT request cm_id in the nvmet event
handler, I see the event handler thread is stuck:
INFO: task kworker/u32:0:6275 blocked for more than 120 seconds.
Tainted: G E 4.7.0-rc2-nvmf-all.3+ #81
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u32:0 D ffff880f90737768 0 6275 2 0x10000080
Workqueue: iw_cm_wq cm_work_handler [iw_cm]
ffff880f90737768 ffff880f907376d8 ffffffff81c0b500 0000000000000005
ffff8810226a4940 ffff88102b894490 ffffffffa02cf4cd ffff880f00000000
ffff880fcd917c00 ffff880f00000000 0000000000000004 ffff880f00000000
Call Trace:
[<ffffffffa02cf4cd>] ? stop_ep_timer+0x2d/0xe0 [iw_cxgb4]
[<ffffffff8163e6a7>] schedule+0x47/0xc0
[<ffffffffa024d276>] ? iw_cm_reject+0x96/0xe0 [iw_cm]
[<ffffffff8163e8e5>] schedule_preempt_disabled+0x15/0x20
[<ffffffff8163fd78>] __mutex_lock_slowpath+0x108/0x310
[<ffffffff8163ffb1>] mutex_lock+0x31/0x50
[<ffffffffa0261498>] rdma_destroy_id+0x38/0x200 [rdma_cm]
[<ffffffffa03145f0>] ? nvmet_rdma_queue_connect+0x1a0/0x1a0 [nvmet_rdma]
[<ffffffffa0262fe1>] ? rdma_create_id+0x171/0x1a0 [rdma_cm]
[<ffffffffa03146f8>] nvmet_rdma_cm_handler+0x108/0x168 [nvmet_rdma]
[<ffffffffa026407a>] iw_conn_req_handler+0x1ca/0x240 [rdma_cm]
[<ffffffffa024efc6>] cm_conn_req_handler+0x606/0x680 [iw_cm]
[<ffffffffa024f109>] process_event+0xc9/0xf0 [iw_cm]
[<ffffffffa024f277>] cm_work_handler+0x147/0x1c0 [iw_cm]
[<ffffffff8107d4f6>] ? trace_event_raw_event_workqueue_execute_start+0x66/0xa0
[<ffffffff81081736>] process_one_work+0x1c6/0x550
...
So I withdraw my comment about nvmet. I think the code is fine as-is. The 2nd
reject results in a no-op since the connection request was rejected by nvmet.
Steve.
next prev parent reply other threads:[~2016-06-14 16:22 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-06 21:23 NVMe over Fabrics RDMA transport drivers Christoph Hellwig
2016-06-06 21:23 ` [PATCH 1/5] blk-mq: Introduce blk_mq_reinit_tagset Christoph Hellwig
2016-06-06 21:23 ` [PATCH 2/5] nvme: add new reconnecting controller state Christoph Hellwig
2016-06-06 21:23 ` [PATCH 3/5] nvme-rdma.h: Add includes for nvme rdma_cm negotiation Christoph Hellwig
2016-06-07 11:59 ` Sagi Grimberg
2016-06-06 21:23 ` [PATCH 4/5] nvmet-rdma: add a NVMe over Fabrics RDMA target driver Christoph Hellwig
2016-06-07 12:00 ` Sagi Grimberg
2016-06-09 21:42 ` Steve Wise
2016-06-09 21:54 ` Ming Lin
2016-06-14 14:32 ` Christoph Hellwig
2016-06-09 23:03 ` Steve Wise
2016-06-14 14:31 ` Christoph Hellwig
2016-06-14 15:14 ` Steve Wise
[not found] ` <00ea01d1c64f$64db8880$2e929980$@opengridcomputing.com>
2016-06-14 15:23 ` Steve Wise
2016-06-14 16:10 ` Steve Wise
2016-06-14 16:22 ` Steve Wise [this message]
2016-06-15 18:32 ` Sagi Grimberg
2016-06-14 16:47 ` Hefty, Sean
2016-06-06 21:23 ` [PATCH 5/5] nvme-rdma: add a NVMe over Fabrics RDMA host driver Christoph Hellwig
2016-06-07 12:00 ` Sagi Grimberg
2016-06-07 14:47 ` Keith Busch
2016-06-07 15:15 ` Freyensee, James P
2016-06-07 11:57 ` NVMe over Fabrics RDMA transport drivers Sagi Grimberg
2016-06-07 12:01 ` Christoph Hellwig
2016-06-07 14:55 ` Woodruff, Robert J
2016-06-07 20:14 ` Steve Wise
2016-06-07 20:27 ` Christoph Hellwig
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='00f701d1c658$efd720d0$cf856270$@opengridcomputing.com' \
--to=swise@opengridcomputing.com \
--cc=armenx.baloyan@intel.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=james.p.freyensee@intel.com \
--cc=keith.busch@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-rdma@vger.kernel.org \
--cc=ming.l@ssi.samsung.com \
--cc=sagi@lightbits.io \
--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;
as well as URLs for NNTP newsgroup(s).