From: Hannes Reinecke <hare@suse.de>
To: "brookxu.cn" <brookxu.cn@gmail.com>,
kbusch@kernel.org, axboe@kernel.dk, hch@lst.de, sagi@grimberg.me
Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] nvme-rdma: unquiesce admin_q before destroy it
Date: Fri, 29 Nov 2024 12:18:07 +0100 [thread overview]
Message-ID: <6fb58b24-cb51-4287-a66c-61eabc4412c8@suse.de> (raw)
In-Reply-To: <9379940137a8dfddb451917c1d069eebaf3c209e.1732368538.git.chunguang.xu@shopee.com>
On 11/23/24 14:37, brookxu.cn wrote:
> From: "Chunguang.xu" <chunguang.xu@shopee.com>
>
> Kernel will hang on destroy admin_q while we create ctrl failed, such
> as following calltrace:
>
> PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme"
> #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15
> #1 [ff61d23de260fc08] schedule at ffffffff8323c014
> #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1
> #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a
> #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006
> #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce [nvme_rdma]
> #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced [nvme_rdma]
> #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b [nvme_rdma]
> #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362 [nvme_fabrics]
> #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25
> RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202
> RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574
> RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004
> RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90
> R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004
> R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500
> ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b
>
> This due to we have quiesced admi_q before cancel requests, but forgot
> to unquiesce before destroy it, as a result we fail to drain the
> pending requests, and hang on blk_mq_freeze_queue_wait() forever. Here
> try to reuse nvme_rdma_teardown_admin_queue() to fix this issue and
> simplify the code.
>
> Reported-by: Yingfu.zhou <yingfu.zhou@shopee.com>
> Signed-off-by: Chunguang.xu <chunguang.xu@shopee.com>
> Signed-off-by: Yue.zhao <yue.zhao@shopee.com>
> ---
> drivers/nvme/host/rdma.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
next prev parent reply other threads:[~2024-11-29 11:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1732368538.git.chunguang.xu@shopee.com>
2024-11-23 13:37 ` [PATCH 1/5] nvme-rdma: unquiesce admin_q before destroy it brookxu.cn
2024-11-25 7:21 ` Christoph Hellwig
2024-11-29 11:18 ` Hannes Reinecke [this message]
2024-12-24 11:53 ` Sagi Grimberg
2024-11-23 13:37 ` [PATCH 2/5] nvme-tcp: no need to quiesec admin_q in nvme_tcp_teardown_io_queues() brookxu.cn
2024-11-25 7:22 ` Christoph Hellwig
2024-11-25 7:55 ` 许春光
2024-11-29 11:18 ` Hannes Reinecke
2024-11-23 13:37 ` [PATCH 3/5] nvme-tcp: simplify nvme_tcp_configure_admin_queue() brookxu.cn
2024-11-25 7:22 ` Christoph Hellwig
2024-11-29 11:19 ` Hannes Reinecke
2024-11-23 13:37 ` [PATCH 4/5] nvme-tcp: remove nvme_tcp_destroy_io_queues() brookxu.cn
2024-11-25 7:24 ` Christoph Hellwig
2024-11-25 7:51 ` 许春光
2024-11-29 11:22 ` Hannes Reinecke
2024-11-23 13:37 ` [PATCH 5/5] nvme-tcp: fix the memleak while create new ctrl failed brookxu.cn
2024-11-25 7:25 ` 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=6fb58b24-cb51-4287-a66c-61eabc4412c8@suse.de \
--to=hare@suse.de \
--cc=axboe@kernel.dk \
--cc=brookxu.cn@gmail.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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