lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6fb58b24-cb51-4287-a66c-61eabc4412c8@suse.de>
Date: Fri, 29 Nov 2024 12:18:07 +0100
From: Hannes Reinecke <hare@...e.de>
To: "brookxu.cn" <brookxu.cn@...il.com>, kbusch@...nel.org, axboe@...nel.dk,
 hch@....de, sagi@...mberg.me
Cc: linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] nvme-rdma: unquiesce admin_q before destroy it

On 11/23/24 14:37, brookxu.cn wrote:
> From: "Chunguang.xu" <chunguang.xu@...pee.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@...pee.com>
> Signed-off-by: Chunguang.xu <chunguang.xu@...pee.com>
> Signed-off-by: Yue.zhao <yue.zhao@...pee.com>
> ---
>   drivers/nvme/host/rdma.c | 8 +-------
>   1 file changed, 1 insertion(+), 7 deletions(-)
> 
Reviewed-by: Hannes Reinecke <hare@...e.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@...e.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ