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

[Zhu Yanjun]

在 2026/11/2 2:08, Deepanshu Kartikey 写道:
> On Mon, Nov 2, 2026 at 1:56 AM Zhu Yanjun <yanjun.zhu@xxxxxxxxx> 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