On Tue, Jan 21, 2025 at 2:11 PM Ian Forbes <ian.forbes@xxxxxxxxxxxx> wrote: > > On Fri, Jan 17, 2025 at 1:20 PM Zack Rusin <zack.rusin@xxxxxxxxxxxx> wrote: > > > > You're going to have to explain that one in the commit message a lot > > better because as is it doesn't make sense to me. Especially the > > !vbo->is_dumb in vmw_bo_free. > > > > z > > The dirty tracker is freed later in vmw_bo_release when it's a > coherent dumb_buffer. Ah, that makes sense. If you could improve the commit message that'd be great (just describe both issues. i.e. the buffer handle being allocated via vmw_gem_object_create_with_handle which create a gem handle that holds the reference and the dirty being explicitly freed for dumb buffers in vmw_bo_release). If you don't have anything too important on your plate right now maybe you could try to come up with some way of testing the creation/destruction of buffers matches. IGT could technically use the debugfs file that Maaz added that should contain all the buffer stats. Even for the above change it'd be a lot nicer if you could just add to the commit message the debugfs output before and after this change while running gnome or kde that shows the leak has been fixed. z
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
