Re: RDMA/mlx5: question about a failed destroy in the SRQ create error path

[Leon Romanovsky <leon@kernel.org>]

On Wed, Oct 28, 2026 at 01:38:57AM -0400, Yuho Choi wrote:
> Hi Leon,
> 
> I have a question about the error path of mlx5_ib_create_srq() (rdma
> for-next, c3e8e9451e6f) and would appreciate your view. When copying
> the response to user space fails, the result of the destroy is not
> checked:
> 
> 	err_core:
> 		mlx5_cmd_destroy_srq(dev, &srq->msrq);
> 
> 	err_usr_kern_srq:
> 		if (udata)
> 			destroy_srq_user(ib_srq->pd, srq, udata);
> 
> If I read it correctly, a failed destroy here would leave the firmware
> SRQ using the SRQ buffer and doorbell record that are then released.
> Since fd89099d635e ("RDMA/mlx5: Issue FW command to destroy SRQ on
> reentry") the SRQ would also be back in dev->srq_table after the core
> frees the ib_srq, so SRQ events and ODP page faults (odp_get_rsc())
> could find freed memory.
> 
> Thanks for explaining in [1] that DESTROY of kernel-owned objects does
> not fail on working firmware. I wondered whether user SRQs might be
> different, since they carry the uid of their context and a DEVX QP of
> the same uid can use them, which 43d781b9fa56 ("RDMA: Allow fail of
> destroy CQ") mentions as a reason for destroy to fail. For example,
> could user space create such a DEVX QP on the new SRQ number (probing
> for it) 

Userspace does not control QP numbers; firmware assigns them. If firmware
considers a number to be in use, neither the kernel nor userspace can obtain it.

Thanks