Re: [PATCH v2 rdma-rc] RDMA/ucma: free a queued CONNECT_REQUEST with its new context

[Jason Gunthorpe <jgg@ziepe.ca>]

On Thu, Nov 12, 2026 at 09:42:00AM +0800, Yuehong Wu wrote:
> --- a/drivers/infiniband/core/ucma.c
> +++ b/drivers/infiniband/core/ucma.c
> @@ -534,8 +534,25 @@ static int ucma_cleanup_ctx_events(struct ucma_context *ctx)
>  	/* Cleanup events not yet reported to the user.*/
>  	mutex_lock(&ctx->file->mut);
>  	list_for_each_entry_safe(uevent, tmp, &ctx->file->event_list, list) {
> -		if (uevent->ctx != ctx)
> +		/*
> +		 * A CONNECT_REQUEST that has not been delivered to user
> +		 * space is queued on the listening context but stores a
> +		 * pointer to the new connection context.  The new context is
> +		 * live in ctx_table before the event is queued, so it can be
> +		 * destroyed before the event is fetched; the event can then
> +		 * no longer be acted upon.  Drop it instead of leaving a
> +		 * dangling conn_req_ctx in the event list.
> +		 */
> +		if (uevent->ctx != ctx) {
> +			if (uevent->resp.event == RDMA_CM_EVENT_CONNECT_REQUEST &&
> +			    uevent->conn_req_ctx == ctx) {
> +				list_del(&uevent->list);
> +				/* Return the slot taken for this request. */
> +				atomic_inc(&uevent->ctx->backlog);
> +				kfree(uevent);
> +			}

The seems like it defeats the cleanup process, or moves the race
around.

I would expect the solution to this problem to hold some kind of
reference while the uevent is alive.

Or perhaps blocking ucma_destory_id while the event still exists.

Jason