Re: [PATCH 5.10] 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] workqueue: WQ_MEM_RECLAIM rescuer deadlock via GFP_KERNEL
--

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

RDMA/hns: Fix WQ_MEM_RECLAIM warning

This commit adds the WQ_MEM_RECLAIM flag to the hns_roce_irq_workq
workqueue to resolve a check_flush_dependency warning triggered during
QP destruction.

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 0468028ffe390..3e49baf2abf61 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
> @@ -6082,7 +6082,8 @@ static int hns_roce_v2_init_eq_table(struct hns_roce_dev *hr_dev)
>  		goto err_request_irq_fail;
>  	}
>  
> -	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]
Adding WQ_MEM_RECLAIM to a workqueue creates a rescuer thread that
executes during memory pressure to guarantee forward progress. Can this
introduce a deadlock if the work items perform GFP_KERNEL allocations?

Looking at the work executed by this queue, flush_work_handle() calls
hns_roce_modify_qp(), which eventually calls hns_roce_alloc_cmd_mailbox().

In hns_roce_alloc_cmd_mailbox(), memory is allocated using 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);
        ...
}

Since the rescuer thread is supposed to relieve memory pressure, blocking
on GFP_KERNEL allocations defeats its purpose and could permanently block
the rescuer. Does this patch trade a flush dependency warning for a
potential deadlock?

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

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