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.
