Re: [PATCH rdma-rc 1/2] RDMA/ucma: Lock the handler in ucma_write_cm_event()

On Mon, Jul 27, 2026 at 10:06:12AM +0200, Norbert Szetei wrote:
> The window is the mutex_lock() itself: the writer sleeps in it while the
> migration reassigns ctx->file.  The list_add_tail() then runs on file B's
> event_list holding only file A's mutex:
> 
>   list_add corruption. prev->next should be next (ffff888101320f30),
>     but was ffff88814a08c418. (prev=ffff88814a075c18).
>   kernel BUG at lib/list_debug.c:32!
>   Call Trace:
>    ucma_write_cm_event+0x36e/0x5e0
> 
> and file A's mut is left held forever, wedging its next writer in D state.
> The uevent is also stranded on a list ucma_cleanup_ctx_events() will not
> walk, so it outlives its context.  /dev/infiniband/rdma_cm is 0666 and no
> RDMA device is involved, so an unprivileged user reaches all of this.
> 
> Take the handler lock, as ucma_cleanup_mc_events() does; ctx->cm_id is
> pinned by the ucma_get_ctx() reference.
> 
> Fixes: a3c9d0fcd371 ("RDMA/ucma: Support write an event into a CM")
> Cc: [email protected]
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Norbert Szetei <[email protected]>
> ---
>  drivers/infiniband/core/ucma.c | 2 ++
>  1 file changed, 2 insertions(+)

There was another one of this mistake too, I'll send a patch

applied to for-next

Thanks,
Jason