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 <[email protected]> > > 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.
