Re: [PATCH] RDMA/cma: Don't warn when device removal races with rdma_resolve_addr()

[Zhu Yanjun <yanjun.zhu@linux.dev>]

在 2026/11/2 2:08, Deepanshu Kartikey 写道:
> On Mon, Nov 2, 2026 at 1:56 AM Zhu Yanjun <yanjun.zhu@linux.dev> wrote:
>>
>> 在 2026/11/1 2:56, Deepanshu Kartikey 写道:
>>> rdma_resolve_addr() on an unbound ID (RDMA_CM_IDLE) first binds it with
>>> cma_bind_addr() and then moves it from RDMA_CM_ADDR_BOUND to
>>> RDMA_CM_ADDR_QUERY with a second cma_comp_exch(). These are two
>>> separate steps. Once the ID is bound it is attached to the device, so
>>> cma_send_device_removal_put() can find it and set RDMA_CM_DEVICE_REMOVAL
>>> before the second step runs. The exchange then fails and hits the
>>> WARN_ON() added by the commit below.
>>>
>>> syzbot triggers this with RDS over rxe, where rds_connect_worker()
>>> calls rdma_resolve_addr() while the rxe device is being deleted:
>>>
>>>     WARNING: drivers/infiniband/core/cma.c:4120 at resolve_prepare_src
>>>     Call Trace:
>>>      rdma_resolve_addr
>>>      rds_ib_conn_path_connect
>>>      rds_connect_worker
>>>
>>> This is a valid race and not a kernel bug. If removal wins before the
>>> bind, cma_bind_addr() already fails and the error is returned to the
>>> caller, and err_state in the same function already ignores a failed
>>> state exchange. The caller gets -EINVAL, and RDS destroys the ID on any
>>> error from rdma_resolve_addr(), so nothing is leaked.
>>>
>>> Drop the WARN_ON() and keep returning -EINVAL, and document in a comment
>>> that the state may change because of device removal.
>> Resend this becase some error occurred.
>>
>> For this specific case, we can consider this behavior expected rather
>> than an error and remove the WARN_ON().
>>
>> However, I'm not sure whether the WARN_ON() is still necessary for other
>> test cases.
>>
> Hi Yanjun,
>
> Thanks for the review. After cma_bind_addr() succeeds the state is
> ADDR_BOUND, and the only legitimate change before the second exchange is
> device removal (cma_send_device_removal_put() sets DEVICE_REMOVAL under
> id_priv->lock without comparing the old state). The other ways to fail
> are ULP misuse (a concurrent destroy or a concurrent call on the same
> ID), and those still get -EINVAL returned to the caller, as before.
> Only the stack trace is dropped.
>
> I can send a v2 that adds a comment explaining the race, and keeps the
> WARN_ON() for states other than DEVICE_REMOVAL if you or the
> maintainers prefer. Please let me know.

I think sending a v2 would be better. It would be good to keep the WARN_ON()

check for other unexpected states and add a comment explaining why 
DEVICE_REMOVAL

is a legitimate state in this race condition. This preserves the 
existing error detection

while making the code easier to understand and maintain.

Yanjun Zhu

>
> Thanks,
> Deepanshu

-- 
Best Regards,
Yanjun.Zhu