[PATCH rdma-next v2] RDMA/cgroup: fix resource leak in DRIVER_FAILURE cleanup path

[PATCH rdma-next v2] RDMA/cgroup: fix resource leak in DRIVER_FAILURE cleanup path

[Tao Cui]

When a driver fails to destroy an RDMA object during ufile cleanup,
the kernel retries and eventually falls back to the
RDMA_REMOVE_DRIVER_FAILURE path. This path sets obj->object = NULL
before calling uverbs_destroy_uobject(), which skips the destroy_hw
callback. Since ib_rdmacg_uncharge() lives inside destroy_hw_idr_uobject(),
the HCA_OBJECT cgroup charge is never released.

Add an explicit ib_rdmacg_uncharge() call in the DRIVER_FAILURE path
to prevent the resource counter leak.  Restrict this to IDR uobjects
(type_class == &uverbs_idr_class), since only IDR objects charge
RDMACG_RESOURCE_HCA_OBJECT in alloc_begin_idr_uobject().  FD objects
never charge this resource, so their cg_obj.cg remains NULL and must
not be passed to ib_rdmacg_uncharge(), which would otherwise dereference
a NULL pointer in rdmacg_uncharge_hierarchy().

Suggested-by: Sashiko AI
Link: https://sashiko.dev/#/patchset/20260518031541.1552942-1-cuitao%40kylinos.cn
Signed-off-by: Tao Cui <cuitao@kylinos.cn>

---
Changes in v2:
- Add type_class check to restrict ib_rdmacg_uncharge() to IDR uobjects
  only, as suggested by Sashiko AI.
---
 drivers/infiniband/core/rdma_core.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/rdma_core.c b/drivers/infiniband/core/rdma_core.c
index 5018ec837056..4fa14f27b76f 100644
--- a/drivers/infiniband/core/rdma_core.c
+++ b/drivers/infiniband/core/rdma_core.c
@@ -917,8 +917,12 @@ static int __uverbs_cleanup_ufile(struct ib_uverbs_file *ufile,
 		 * racing with a lookup_get.
 		 */
 		WARN_ON(uverbs_try_lock_object(obj, UVERBS_LOOKUP_WRITE));
-		if (reason == RDMA_REMOVE_DRIVER_FAILURE)
+		if (reason == RDMA_REMOVE_DRIVER_FAILURE) {
 			obj->object = NULL;
+			if (obj->uapi_object->type_class == &uverbs_idr_class)
+				ib_rdmacg_uncharge(&obj->cg_obj, ib_dev,
+						   RDMACG_RESOURCE_HCA_OBJECT);
+		}
 		if (!uverbs_destroy_uobject(obj, reason, &attrs))
 			ret = 0;
 		else
-- 
2.43.0

Re: [PATCH rdma-next v2] RDMA/cgroup: fix resource leak in DRIVER_FAILURE cleanup path

[Jason Gunthorpe]

On Wed, May 20, 2026 at 07:55:06PM +0800, Tao Cui wrote:
> When a driver fails to destroy an RDMA object during ufile cleanup,
> the kernel retries and eventually falls back to the
> RDMA_REMOVE_DRIVER_FAILURE path. This path sets obj->object = NULL
> before calling uverbs_destroy_uobject(), which skips the destroy_hw
> callback. Since ib_rdmacg_uncharge() lives inside destroy_hw_idr_uobject(),
> the HCA_OBJECT cgroup charge is never released.
> 
> Add an explicit ib_rdmacg_uncharge() call in the DRIVER_FAILURE path
> to prevent the resource counter leak.  Restrict this to IDR uobjects
> (type_class == &uverbs_idr_class), since only IDR objects charge
> RDMACG_RESOURCE_HCA_OBJECT in alloc_begin_idr_uobject().  FD objects
> never charge this resource, so their cg_obj.cg remains NULL and must
> not be passed to ib_rdmacg_uncharge(), which would otherwise dereference
> a NULL pointer in rdmacg_uncharge_hierarchy().
> 
> Suggested-by: Sashiko AI
> Link: https://sashiko.dev/#/patchset/20260518031541.1552942-1-cuitao%40kylinos.cn
> Signed-off-by: Tao Cui <cuitao@kylinos.cn>
> 
> ---
> Changes in v2:
> - Add type_class check to restrict ib_rdmacg_uncharge() to IDR uobjects
>   only, as suggested by Sashiko AI.
> ---
>  drivers/infiniband/core/rdma_core.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/infiniband/core/rdma_core.c b/drivers/infiniband/core/rdma_core.c
> index 5018ec837056..4fa14f27b76f 100644
> --- a/drivers/infiniband/core/rdma_core.c
> +++ b/drivers/infiniband/core/rdma_core.c
> @@ -917,8 +917,12 @@ static int __uverbs_cleanup_ufile(struct ib_uverbs_file *ufile,
>  		 * racing with a lookup_get.
>  		 */
>  		WARN_ON(uverbs_try_lock_object(obj, UVERBS_LOOKUP_WRITE));
> -		if (reason == RDMA_REMOVE_DRIVER_FAILURE)
> +		if (reason == RDMA_REMOVE_DRIVER_FAILURE) {
>  			obj->object = NULL;
> +			if (obj->uapi_object->type_class == &uverbs_idr_class)
> +				ib_rdmacg_uncharge(&obj->cg_obj, ib_dev,
> +						   RDMACG_RESOURCE_HCA_OBJECT);
> +		}

No, this is AI slop, the point of this flow is to try to keep the
kernel hobbling forward when it has experienced a critical
failure. The only way to get here includes a WARN_ON.

We don't need to do any more than the bare minimal to not crash -
which is only to clean the ufile->uobjects

Jason