[PATCH 5.15] RDMA/hns: Fix WQ_MEM_RECLAIM warning

[PATCH 5.15] RDMA/hns: Fix WQ_MEM_RECLAIM warning

[Roman Demidov]

From: Chengchang Tang <tangchengchang@huawei.com>

commit c0a26bbd3f99b7b03f072e3409aff4e6ec8af6f6 upstream.

When sunrpc is used, if a reset triggered, our wq may lead the
following trace:

workqueue: WQ_MEM_RECLAIM xprtiod:xprt_rdma_connect_worker [rpcrdma]
is flushing !WQ_MEM_RECLAIM hns_roce_irq_workq:flush_work_handle
[hns_roce_hw_v2]
WARNING: CPU: 0 PID: 8250 at kernel/workqueue.c:2644 check_flush_dependency+0xe0/0x144
Call trace:
  check_flush_dependency+0xe0/0x144
  start_flush_work.constprop.0+0x1d0/0x2f0
  __flush_work.isra.0+0x40/0xb0
  flush_work+0x14/0x30
  hns_roce_v2_destroy_qp+0xac/0x1e0 [hns_roce_hw_v2]
  ib_destroy_qp_user+0x9c/0x2b4
  rdma_destroy_qp+0x34/0xb0
  rpcrdma_ep_destroy+0x28/0xcc [rpcrdma]
  rpcrdma_ep_put+0x74/0xb4 [rpcrdma]
  rpcrdma_xprt_disconnect+0x1d8/0x260 [rpcrdma]
  xprt_rdma_connect_worker+0xc0/0x120 [rpcrdma]
  process_one_work+0x1cc/0x4d0
  worker_thread+0x154/0x414
  kthread+0x104/0x144
  ret_from_fork+0x10/0x18

Since QP destruction frees memory, this wq should have the WQ_MEM_RECLAIM.

Fixes: ffd541d45726 ("RDMA/hns: Add the workqueue framework for flush cqe handler")
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
Link: https://patch.msgid.link/20260104064057.1582216-2-huangjunxian6@hisilicon.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Roman Demidov <roman.demidov.nn@gmail.com>
---
Backport fix for CVE-2026-46265

 drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
index 43b661f97188..32d8a4eb385b 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
@@ -6209,7 +6209,8 @@ static int hns_roce_v2_init_eq_table(struct hns_roce_dev *hr_dev)
 		}
 	}
 
-	hr_dev->irq_workq = alloc_ordered_workqueue("hns_roce_irq_workq", 0);
+	hr_dev->irq_workq = alloc_ordered_workqueue("hns_roce_irq_workq",
+						    WQ_MEM_RECLAIM);
 	if (!hr_dev->irq_workq) {
 		dev_err(dev, "failed to create irq workqueue.\n");
 		ret = -ENOMEM;
-- 
2.53.0

Re: [PATCH 5.15] RDMA/hns: Fix WQ_MEM_RECLAIM warning

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] RDMA/hns: WQ_MEM_RECLAIM violation causing deadlock risk
--

commit d3658f8cd2795fb06b4ce731d99702798127a921
Author: Chengchang Tang <tangchengchang@huawei.com>

RDMA/hns: Fix WQ_MEM_RECLAIM warning
    
This commit adds the WQ_MEM_RECLAIM flag to irq_workq to resolve a flush
dependency warning during xprt_rdma_connect_worker execution. It notes that
since QP destruction frees memory, this workqueue should have WQ_MEM_RECLAIM.

Link: https://patch.msgid.link/20260104064057.1582216-2-huangjunxian6@hisilicon.com

> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
> index d5f3faa1627a4..f0a33562f8657 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
> @@ -6119,7 +6119,8 @@ static int hns_roce_v2_init_eq_table(struct hns_roce_dev *hr_dev)
>  		}
>  	}
>  
> -	hr_dev->irq_workq = alloc_ordered_workqueue("hns_roce_irq_workq", 0);
> +	hr_dev->irq_workq = alloc_ordered_workqueue("hns_roce_irq_workq",
> +						    WQ_MEM_RECLAIM);

[Severity: High]
Does adding WQ_MEM_RECLAIM here introduce a deadlock risk under memory
pressure?

The WQ_MEM_RECLAIM flag requires that works on this queue must not block on
memory allocations. However, flush_work_handle() runs on this queue and makes
synchronous calls that trigger hardware QP modifications:

drivers/infiniband/hw/hns/hns_roce_qp.c:flush_work_handle() {
    ...
		ret = hns_roce_modify_qp(&hr_qp->ibqp, &attr, attr_mask, NULL);
    ...
}

These modifications eventually lead to allocations with GFP_KERNEL:

drivers/infiniband/hw/hns/hns_roce_cmd.c:hns_roce_alloc_cmd_mailbox() {
    ...
	mailbox = kmalloc(sizeof(*mailbox), GFP_KERNEL);
	if (!mailbox)
		return ERR_PTR(-ENOMEM);

	mailbox->buf =
		dma_pool_alloc(hr_dev->cmd.pool, GFP_KERNEL, &mailbox->dma);
    ...
}

When the system is under heavy memory pressure, the workqueue rescuer thread
activates to guarantee forward progress. The rescuer thread will block in
these GFP_KERNEL allocations waiting for memory reclaim, while memory reclaim
might be waiting for this workqueue to process items (as seen in the rpcrdma
trace in the commit message).

Will this unresolvable circular dependency cause a hard deadlock?

>  	if (!hr_dev->irq_workq) {
>  		dev_err(dev, "failed to create irq workqueue.\n");
>  		ret = -ENOMEM;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261006081857.125617-1-roman.demidov.nn@gmail.com?part=1