Re: [PATCH v2] accel/qaic: fix GEM object refcount leak in qaic_attach_slice_bo_ioctl

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Jul 29, 2026 at 03:19:38PM -0600, Jeff Hugo wrote:
> 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 <gregkh@linuxfoundation.org>
> 
> This tag seems wrong, as there was nothing I can find on V1 in Lore which
> indicates this tag is appropriate.

Yes, I did not suggest any of these, and the author should have
withdrawn all submissions as they were obviously not correct.