[PATCH] nvmet-rdma: handle commands of established queue outside the CM handler

[Keith Busch]

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?