Re: drm/vmwgfx: graphics memory not returned,after all GEM objects are released

[Jellis Onsea | AccessWeb <jellis@accessweb.be>]

Hi Maaz,

Yes, it is set up here now.

One practical detail: 26.1.7 never reached this machine. Arch upgraded 
us from 26.1.6 to 26.2.0 in one step on 17 August, so rather than the 
release I am using the build we made on 7 August, which is 26.1.6 with 
your commit 2ed36c6 applied. I diffed that tree against the mesa-26.1.7 
tag: src/gallium/winsys/svga/ and src/gallium/drivers/svga/ are 
identical, so for the svga paths it is that version. Our vmwgfx module 
reports 2.21.0.0, so have_drm_2_21 is true and the new branch is the one 
that runs.

Results will take a day or two, and I would rather explain why than send 
you a number too early. With 3D enabled our leak has run between 5 and 
161 MB/hour, and the debugfs counter we track is logged in 10 MB steps, 
so a short window cannot resolve it. A ten-minute run last night came 
out flat, which says nothing either way. I will run a multi-hour window 
on stock mesa and an identical window on the patched build, under the 
same synthetic render load, and send you both.

Two things you may want to know in the meantime.

First, mesa 26.2.0 does not contain your fix. It was tagged on 5 August, 
a week before 26.1.7, so it predates the backport:

   mesa-26.1.6         29 Jul 2026   absent
   mesa-26.2.0         05 Aug 2026   absent    (what Arch ships today)
   mesa-26.1.7         12 Aug 2026   present
   origin/staging/26.2               present
   origin/main                       present

In the 26.2.0 tree, vmw_screen_dri.c:331 still reads

   ret = drmPrimeHandleToFD(vws->ioctl.drm_fd, vsrf->sid, ...)

staging/26.2 and main both carry the fix, so 26.2.1 should bring it 
along. Until then every distribution that moves from 26.1.7 to 26.2.0 
loses it again.

Second, enabling 3D on 26.2.0 took our desktop down, in the dmabuf path:

   dmabuf import failed to mmap: Invalid argument   (x4)
   plasma-plasmashell.service: Main process exited, code=dumped, 
status=11/SEGV

There is one reliable way to trigger it: hovering the mouse over a task 
manager icon of a running window, so that Plasma raises the window 
thumbnail preview. That killed plasmashell every single time. As long as 
we stayed away from those icons the session looked stable. A thumbnail 
preview is a dmabuf import of another client's buffer, which fits the 
error above.

Once it starts, systemd restarts plasmashell, the shell rebuilds the 
panel and dies again: three crashes within eight seconds, then the 
restart limit gave up and we were left with an empty desktop. A manual 
restart behaved the same way.

The precondition is 3D enabled together with LIBGL_ALWAYS_SOFTWARE=1, 
which is the configuration in our original report of 5 August. Removing 
that variable, so the session really runs on svga, makes it stable: the 
same hover over the same icons is now uneventful, and the desktop has 
been up since.

I am not claiming your fix addresses that. We have not tested it, and 
this was on 26.2.0, which does not have it. But it is the same handle 
export path and it is now reproducible on demand here, which it was not 
before. If a backtrace or an strace of the failing mmap would help, say 
the word.

Finally, a small thing in the patch itself, which does not affect us 
since we are on 2.21: in vmw_drm_surface_get_handle(), ret is declared 
uninitialised, and when have_drm_2_21 is false while vsrf->buf is 
non-NULL neither branch assigns it. The following "if (ret)" then reads 
an indeterminate value.


Best regards,
Jellis

Op 18-08-2026 om 00:02 schreef Maaz Mombasawala:
> For the 3D enabled case, that sounds a lot like the memory leak for which I submitted the
> fix to mesa recently. The fix has been included in mesa version 26.1.7, could you try with
> that version? I see you're using mesa 26.1.6 right now.
>