Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] The obj_cgroup reference acquired in ttm_buffer_object_transfer() is leaked on the error path. --
commit 1cccf014e6a8377ef4e98ad7bba76a7229069c1c Author: Dave Airlie <[email protected]> Subject: ttm: add objcg pointer to bo and tt (v3) This commit adds the obj cgroup pointer to the bo and tt structs, and sets it between them. > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c > b/drivers/gpu/drm/ttm/ttm_bo_util.c > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c > @@ -238,6 +238,8 @@ static int ttm_buffer_object_transfer(struct > ttm_buffer_object *bo, > return -ENOMEM; > > fbo->base = *bo; > + if (bo->objcg) > + obj_cgroup_get(bo->objcg); > > /** > * Fix up members that we shouldn't copy directly: [ ... ] > ret = dma_resv_trylock(&fbo->base.base._resv); > WARN_ON(!ret); > > ret = dma_resv_reserve_fences(&fbo->base.base._resv, > TTM_NUM_MOVE_FENCES); > if (ret) { > dma_resv_unlock(&fbo->base.base._resv); > kfree(fbo); > return ret; > } [Severity: High] Does this error path leak the objcg reference? We acquire a new reference for the transfer buffer object with obj_cgroup_get() earlier in ttm_buffer_object_transfer(). If dma_resv_reserve_fences() fails, this error path frees the memory for fbo and returns, but it doesn't seem to drop the newly acquired objcg reference. Should there be a call to obj_cgroup_put() before returning here to ensure the memory cgroup doesn't stay pinned indefinitely? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=4
