On 6/28/2026 5:51 AM, WenTao Liang wrote:
drm_gem_object_lookup() acquires a GEM object reference on success. All
error paths correctly release it via put_bo, but the success path returns
without calling drm_gem_object_put(obj). Since list_add_tail does not
transfer ownership, the GEM object reference is permanently leaked on
each successful call.
NACK.
put() is specifically not called in the success case as data structures
which depend on the BO are not released until detach_slice_bo(), which
happens to be where the corresponding put() is. It is also not possible
to successfully call attach_slice() more than once without a
corresponding detach_slice_bo().
The get() and put() operations for the concerned paths are currently
balanced, but this patch will actually introduce an unbalanced state
(extra put() operations).
As far as the impact of not having this patch per the commit text
(memory leak) I'm aware of many memory stress tests, yet I recall no
reports of memory leaks from attach_slice(). You will need to provide
proof, from actual testing, that this is an issue.
Suggested-by: Greg KH <[email protected]>
This tag seems wrong, as there was nothing I can find on V1 in Lore
which indicates this tag is appropriate.
Fixes: 75af0a585af9 ("accel/qaic: Grab ch_lock during QAIC_ATTACH_SLICE_BO")
Cc: [email protected]
Signed-off-by: WenTao Liang <[email protected]>
---
Changes in v2:
- Fix patch format based on reviewer feedback
---
drivers/accel/qaic/qaic_data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/accel/qaic/qaic_data.c b/drivers/accel/qaic/qaic_data.c
index 1e4c579d2725..b17df7bf565d 100644
--- a/drivers/accel/qaic/qaic_data.c
+++ b/drivers/accel/qaic/qaic_data.c
@@ -1084,6 +1084,7 @@ int qaic_attach_slice_bo_ioctl(struct drm_device *dev,
void *data, struct drm_fi
bo->sliced = true;
list_add_tail(&bo->bo_list, &bo->dbc->bo_lists);
+ drm_gem_object_put(obj);
srcu_read_unlock(&dbc->ch_lock, rcu_id);
mutex_unlock(&bo->lock);
kfree(slice_ent);
