From: Keith Busch <kbusch@kernel.org>
To: Shin'ichiro Kawasaki <shinichiro.kawasaki@opensource.wdc.com>
Cc: linux-nvme@lists.infradead.org,
Christoph Hellwig <hch@infradead.org>,
Sagi Grimberg <sagi@grimberg.me>,
Chaitanya Kulkarni <kch@nvidia.com>,
Surabhi Gogte <sgogte@purestorage.com>,
Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Subject: Re: [PATCH] nvmet-rdma: handle commands of established queue outside the CM handler
Date: Fri, 23 Oct 2026 16:41:33 -0600 [thread overview]
Message-ID: <atvinQcDcpB7pzjK@kbusch-mbp> (raw)
In-Reply-To: <20260922124447.588057-1-shinichiro.kawasaki@opensource.wdc.com>
On Tue, Sep 22, 2026 at 09:44:47PM +0900, Shin'ichiro Kawasaki wrote:
> WARNING: possible circular locking dependency detected
> rm/7346 is trying to acquire lock:
> (&id_priv->handler_mutex){+.+.}-{4:4}, at: rdma_destroy_id+0x17/0x20 [rdma_cm]
> but task is already holding lock:
> (nvmet_config_sem){++++}-{4:4}, at: nvmet_port_subsys_drop_link+0x52/0x340 [nvmet]
>
> -> #1 (nvmet_config_sem){++++}-{4:4}:
> down_read+0xa6/0x530
> nvmet_find_get_subsys+0x1f4/0x630 [nvmet]
> nvmet_ctrl_find_get+0xaa/0x320 [nvmet]
> nvmet_execute_io_connect+0x1e0/0x480 [nvmet]
> nvmet_rdma_execute_command+0x18e/0x480 [nvmet_rdma]
> nvmet_rdma_handle_command+0x428/0xb30 [nvmet_rdma]
> nvmet_rdma_cm_handler+0x8a8/0x30f0 [nvmet_rdma]
> CPU0 cma_cm_event_handlercma_cm_event_handler+0xb0/0x3c0 [rdma_cm]
> cma_ib_handler+0x28a/0x9b1 [rdma_cm]
> cm_process_work+0x4b/0x3e1 [ib_cm]
> cm_work_handler+0x2485/0xac10 [ib_cm]
>
> -> #0 (&id_priv->handler_mutex){+.+.}-{4:4}:
> rdma_destroy_id+0x17/0x20 [rdma_cm]
> nvmet_rdma_disable_port+0x44/0x300 [nvmet_rdma]
> nvmet_rdma_remove_port+0x42/0x60 [nvmet_rdma]
> nvmet_disable_port+0x120/0x1f0 [nvmet]
> nvmet_port_subsys_drop_link+0x261/0x340 [nvmet]
> configfs_unlink+0x36d/0x790
> vfs_unlink+0x278/0xb40
> filename_unlinkat+0x31d/0x670
> __x64_sys_unlinkat+0xae/0x100
>
> other info that might help us debug this:
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(nvmet_config_sem);
> lock(&id_priv->handler_mutex);
> lock(nvmet_config_sem);
> lock(&id_priv->handler_mutex);
>
> *** DEADLOCK ***
>
> This WARN can be recreated by repeating the blktests test case nvme/004
> or nvme/032 for rdma transport and rxe driver.
I think this might be a false positive. The handler_mutex taken in
rdma_destroy_id() belongs to the listener, while the one held across
ESTABLISHED belongs to the child cm_id. Is there ever an actual hang, or
just the lockdep splat?
next prev parent reply other threads:[~2026-10-23 22:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 12:44 [PATCH] nvmet-rdma: handle commands of established queue outside the CM handler Shin'ichiro Kawasaki
2026-10-23 22:41 ` Keith Busch [this message]
2026-10-25 12:54 ` Shin'ichiro Kawasaki
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=atvinQcDcpB7pzjK@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=hch@infradead.org \
--cc=kch@nvidia.com \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=sgogte@purestorage.com \
--cc=shinichiro.kawasaki@opensource.wdc.com \
--cc=shinichiro.kawasaki@wdc.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