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

[sashiko-bot@kernel.org]

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