Re: [rdma] "rdma link del" operation hangs at wait_for_completion() when a file descriptor is in use.

[Jason Gunthorpe <jgg@ziepe.ca>]

On Sun, Mar 01, 2026 at 04:43:55PM +0900, Tetsuo Handa wrote:
> On 2026/03/01 7:35, Tetsuo Handa wrote:
> > On 2026/03/01 1:43, Jason Gunthorpe wrote:
> >> On Sat, Feb 28, 2026 at 03:07:29PM +0900, Tetsuo Handa wrote:
> >>> On 2025/12/04 17:26, Tetsuo Handa wrote:
> >>>> I found that running the attached example program causes khungtaskd message. What is wrong?
> >>>
> >>> I found that this is a deadlock caused by "struct ib_device_ops"->disassociate_ucontext == NULL.
> >>> If the thread which called ib_uverbs_remove_one() is unable to call ib_uverbs_release_file()
> >>>  from ib_uverbs_close() because it is blocked at
> >>> wait_for_completion(), it forms a deadlock.
> >>
> >> That doesn't sound right at all, the wait_for_completion is waiting
> >> for other threads to let go of the context before closing it. rxe/etc
> >> that syzkaller is testing don't support disassociate so they need to
> >> wait.
> > 
> > This issue was not found by syzkaller. Please see the reproducer.
> > 
> >>
> >> If the wait gets stuck that is a different issue.
> > 
> > My question is how we can support disassociate...
> > 
> 
> As of eb71ab2bf722 in linux.git, this problem is still reproducible.
> 
> If you add debug printk() like below, you will be able to confirm that
> ib_uverbs_remove_one() cannot return unless file descriptor is closed.

That's right - that is exactly how it designed to work.

Without disassociate support in the driver you *cannot* safely unload
the driver while FDs are open, to protect the kernel from UAF crashes
we sleep here.

I have no idea what it would take to add disassociate to siw or rxe,
they clearly should have it given how easy it is to trigger a "driver
unbind" through ip route..

Alternatively maybe we should make 'ip link del' fail early in these
case when a FD is open instead of infinite way.

Jason