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

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

[Jellis Onsea | AccessWeb]

Hi Zack,

I'm reporting a memory issue in vmwgfx where graphics memory is not 
returned to the system even after every DRM client has released its GEM 
objects. Only a reboot frees it. This comes out of KDE bug 523812, which 
was closed as RESOLVED UPSTREAM with the assessment that this looks like 
a driver-side leak rather than a compositor one.

- Environment:

     Guest:      CachyOS (Arch-based), kernel 7.1.5 and 7.1.6
     Host:       VMware Workstation on Windows, AMD Ryzen 9 7950X
     Driver:     vmwgfx 2.21.0.0, VMware SVGA II
     Renderer:   llvmpipe (LIBGL_ALWAYS_SOFTWARE=1, see note below)
     Compositor: KWin 6.7.3, Plasma Wayland, 3 x 1920x1080 @ 60 Hz
     RAM:        31 GiB, zram swap
     3D accel:   disabled in the VM settings

- What happens:

During normal desktop use, buffers of exactly 8355840 bytes accumulate. 
That is 1920 x 1088 x 4 — one screen-sized 32-bit framebuffer with the 
height padded to a multiple of 64. Growth is tied to rendering activity, 
not to uptime: an unattended session leaked exactly zero bytes over 7.3 
hours, while active use adds roughly 1.4 GB/hour.

At 9 hours of uptime, kwin_wayland held 1846 GEM objects, 1553 of them 
that exact size. All of them had pin_count = 0. At 34.5 hours it was 
8057 objects.

- The measurement that points at the driver:

I logged out of the Plasma session and logged back in, without 
rebooting. That restarts the compositor (pid 2612 -> 3156650) and closes 
its DRM fd, so the kernel drops all its GEM references.

                                   before logout      after re-login
     GEM objects, all clients      8139               19
     system_ttm usage              49.47 GB           45.80 GB
     GPUActive (/proc/meminfo)     10.86 GB           11.06 GB
     MemAvailable                  11.06 GB           13.32 GB

So: no DRM client held more than 19 GEM objects in total, yet roughly 11 
GB remained accounted as GPUActive and was not returned. The ~2.3 GB 
gained in MemAvailable is very likely just the browsers and editors from 
the old session exiting, not graphics memory.

A reboot immediately afterwards did return it:

     GPUActive     0.11 GB
     RAM in use    4.5 GB of 31 GB   (was 18 GB before the reboot)

- Caveats I want to be upfront avout:

- system_ttm reporting 46-49 GB on a machine with 31 GiB of RAM is 
something I cannot explain. My assumption is that TTM accounts pages it 
has evicted to shmem, while GPUActive counts only resident ones. If that 
assumption is wrong, the volume figures need reinterpreting. The object 
counts and the fact that a reboot is required stand either way.
- Summing the reported sizes of the GEM objects gives ~46 GB, which also 
exceeds physical RAM, so that sum over-counts — presumably shared or 
multiply-mapped objects. I would trust the counts, not that total.
- This is a CachyOS kernel, not vanilla. I have not yet reproduced on 
mainline. I am happy to test a vanilla or drm-tip kernel if that would 
help; the machine reproduces this within a working day.
- LIBGL_ALWAYS_SOFTWARE=1 is set here to work around an older, separate 
vmwgfx surface-handle problem that crashed Chromium/Electron compositor 
threads with SIGILL. The behaviour described above occurs with that 
workaround in place.

- Possibly related earlier work:

I am aware of the dumb-buffer leak fixes in vmwgfx from the 6.10 era 
("drm/vmwgfx: Fix handling of dumb buffers", "drm/vmwgfx: Fix dumb 
buffer leak") and the rework that made GEM handles own the dumb buffer. 
The buffers accumulating here are exactly screen-sized dumb buffers, so 
this may well be in the same area, but on a much newer kernel, so either 
something remains or it is a regression. I did not find an open report 
matching this.

- How to reproduce the measurements:

     # object count and per-client totals (root)
     grep -c bytes /sys/kernel/debug/dri/0/vmwgfx_gem_info
     awk '/^ *pid/{p=$2" "$4} /bytes/{n[p]++; s[p]+=$2} \
          END{for(k in n) printf "%-26s %6d objects %9.1f MB\n", k, 
n[k], s[k]/1048576}' \
         /sys/kernel/debug/dri/0/vmwgfx_gem_info | sort -k3 -rn

     # pool usage (root)
     awk '/usage:/{print $2}' /sys/kernel/debug/dri/0/system_ttm

     # resident graphics memory
     grep -E 'GPUActive|GPUReclaim' /proc/meminfo

Use the desktop normally for a few hours; a browser window with a 
looping CSS animation makes it measurable within minutes. Opening and 
closing 32 windows produced no growth at all, so it is the continuous 
rendering that drives it.

Happy to run anything specific, apply a debug patch, or test a different 
kernel.


Regards,

Jellis Onsea
AccessWeb

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

[Zack Rusin]

[-- Attachment #1: Type: text/plain, Size: 5423 bytes --]

On Wed, Aug 5, 2026 at 4:41 PM Jellis Onsea | AccessWeb
<jellis@accessweb.be> wrote:
>
> Hi Zack,
>
> I'm reporting a memory issue in vmwgfx where graphics memory is not
> returned to the system even after every DRM client has released its GEM
> objects. Only a reboot frees it. This comes out of KDE bug 523812, which
> was closed as RESOLVED UPSTREAM with the assessment that this looks like
> a driver-side leak rather than a compositor one.
>
> - Environment:
>
>      Guest:      CachyOS (Arch-based), kernel 7.1.5 and 7.1.6
>      Host:       VMware Workstation on Windows, AMD Ryzen 9 7950X
>      Driver:     vmwgfx 2.21.0.0, VMware SVGA II
>      Renderer:   llvmpipe (LIBGL_ALWAYS_SOFTWARE=1, see note below)
>      Compositor: KWin 6.7.3, Plasma Wayland, 3 x 1920x1080 @ 60 Hz
>      RAM:        31 GiB, zram swap
>      3D accel:   disabled in the VM settings
>
> - What happens:
>
> During normal desktop use, buffers of exactly 8355840 bytes accumulate.
> That is 1920 x 1088 x 4 — one screen-sized 32-bit framebuffer with the
> height padded to a multiple of 64. Growth is tied to rendering activity,
> not to uptime: an unattended session leaked exactly zero bytes over 7.3
> hours, while active use adds roughly 1.4 GB/hour.
>
> At 9 hours of uptime, kwin_wayland held 1846 GEM objects, 1553 of them
> that exact size. All of them had pin_count = 0. At 34.5 hours it was
> 8057 objects.
>
> - The measurement that points at the driver:
>
> I logged out of the Plasma session and logged back in, without
> rebooting. That restarts the compositor (pid 2612 -> 3156650) and closes
> its DRM fd, so the kernel drops all its GEM references.
>
>                                    before logout      after re-login
>      GEM objects, all clients      8139               19
>      system_ttm usage              49.47 GB           45.80 GB
>      GPUActive (/proc/meminfo)     10.86 GB           11.06 GB
>      MemAvailable                  11.06 GB           13.32 GB
>
> So: no DRM client held more than 19 GEM objects in total, yet roughly 11
> GB remained accounted as GPUActive and was not returned. The ~2.3 GB
> gained in MemAvailable is very likely just the browsers and editors from
> the old session exiting, not graphics memory.
>
> A reboot immediately afterwards did return it:
>
>      GPUActive     0.11 GB
>      RAM in use    4.5 GB of 31 GB   (was 18 GB before the reboot)
>
> - Caveats I want to be upfront avout:
>
> - system_ttm reporting 46-49 GB on a machine with 31 GiB of RAM is
> something I cannot explain. My assumption is that TTM accounts pages it
> has evicted to shmem, while GPUActive counts only resident ones. If that
> assumption is wrong, the volume figures need reinterpreting. The object
> counts and the fact that a reboot is required stand either way.
> - Summing the reported sizes of the GEM objects gives ~46 GB, which also
> exceeds physical RAM, so that sum over-counts — presumably shared or
> multiply-mapped objects. I would trust the counts, not that total.
> - This is a CachyOS kernel, not vanilla. I have not yet reproduced on
> mainline. I am happy to test a vanilla or drm-tip kernel if that would
> help; the machine reproduces this within a working day.
> - LIBGL_ALWAYS_SOFTWARE=1 is set here to work around an older, separate
> vmwgfx surface-handle problem that crashed Chromium/Electron compositor
> threads with SIGILL. The behaviour described above occurs with that
> workaround in place.
>
> - Possibly related earlier work:
>
> I am aware of the dumb-buffer leak fixes in vmwgfx from the 6.10 era
> ("drm/vmwgfx: Fix handling of dumb buffers", "drm/vmwgfx: Fix dumb
> buffer leak") and the rework that made GEM handles own the dumb buffer.
> The buffers accumulating here are exactly screen-sized dumb buffers, so
> this may well be in the same area, but on a much newer kernel, so either
> something remains or it is a regression. I did not find an open report
> matching this.
>
> - How to reproduce the measurements:
>
>      # object count and per-client totals (root)
>      grep -c bytes /sys/kernel/debug/dri/0/vmwgfx_gem_info
>      awk '/^ *pid/{p=$2" "$4} /bytes/{n[p]++; s[p]+=$2} \
>           END{for(k in n) printf "%-26s %6d objects %9.1f MB\n", k,
> n[k], s[k]/1048576}' \
>          /sys/kernel/debug/dri/0/vmwgfx_gem_info | sort -k3 -rn
>
>      # pool usage (root)
>      awk '/usage:/{print $2}' /sys/kernel/debug/dri/0/system_ttm
>
>      # resident graphics memory
>      grep -E 'GPUActive|GPUReclaim' /proc/meminfo
>
> Use the desktop normally for a few hours; a browser window with a
> looping CSS animation makes it measurable within minutes. Opening and
> closing 32 windows produced no growth at all, so it is the continuous
> rendering that drives it.
>
> Happy to run anything specific, apply a debug patch, or test a different
> kernel.

Yea, this is because we never added explicit prime exports
derefs/destroy ioctl's to kernel's drm uapi so all userspace assumes
that prime always operates on gem buffers but that wasn't the case for
vmwgfx so gem closing the resources created from fd handles did
nothing on vmwgfx and every one of them leaked.

Maaz just submitted a fix for that to mesa:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43386
If you can I'd give that a try.

z

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5414 bytes --]

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

[Maaz Mombasawala]

Hi,
As Zack mentioned, we have had issues with kwin attempting to gem_close() handles
causing a memory leak.
I have submitted a fix for it in mesa and it has been backported to 26.1 as well.
Could you please test things again with that fix?

To do so you can build the svga mesa driver (https://gitlab.freedesktop.org/mesa/mesa)
on either the main branch or staging/26.1 branch.
Alternately you can also wait for the release of the next release of mesa 26.1 which
would happen august 12th, or mesa 26.2 which should be our august 29th.

-- 
Maaz Mombasawala <maaz.mombasawala@broadcom.com>

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

[Jellis Onsea | AccessWeb]

Hi Maaz, Zack,

I have a test result, but not the one you asked for.. the bug stopped
reproducing before I could test the patch, and the reason may be useful 
to you.

Short version: enabling 3D acceleration on the VMware host made the leak 
go away, with the stock distribution mesa. No patch involved.

-- What I changed:

Until 7 August this guest ran with 3D acceleration disabled in the VM 
settings, and additionally forced llvmpipe via LIBGL_ALWAYS_SOFTWARE=1. 
That was the configuration in my original report.

I enabled 3D on the host and removed the LIBGL_ALWAYS_SOFTWARE override, 
so the whole session -- kwin_wayland, plasmashell, clients -- now runs 
on svga:

     OpenGL renderer string: SVGA3D; build: RELEASE;  LLVM;
     Driver: VMware (SVGA3D)
     mesa 26.1.6-arch3.1   (distribution build, NOT patched)

-- Measurements:

Sampled every 15 minutes. system_ttm and mob_ttm are the two TTM pools 
from /sys/kernel/debug/dri/0/, "total" is their combined growth:

session start        hours   system_ttm        mob_ttm         total objects
  
------------------------------------------------------------------------------
     2026-08-02 20:37       7.8    4.73 -> 15.09   0.023 -> 0.023 
+1355 MB/h   753 -> 2184
     2026-08-03 04:36      34.8    0.11 -> 46.57   0.023 -> 0.023 
+1367 MB/h    23 -> 8211
     2026-08-04 15:37      33.1    0.10 -> 32.07   0.023 -> 0.023 
+989 MB/h    31 -> 5586
     2026-08-06 00:59      25.7    0.32 -> 17.07   0.023 -> 0.023 
+667 MB/h    49 -> 2680
     --- 3D enabled, svga in use from here ---
     2026-08-07 02:48      15.6    0.06 ->  0.05   0.131 -> 0.216 
+5 MB/h    85 ->  244
     2026-08-07 18:35      18.2    0.08 ->  0.19   0.266 -> 0.555 
+22 MB/h  1357 -> 3272

Same machine, same kernel (7.1.6), same mesa package, comparable desktop 
use. The last row is a full working day plus a night.

Two details that may matter more than the totals:

- --mob_ttm never moved in any of the four pre-3D sessions-- 409 samples 
over four days, constant at 0.023 GB. With svga it moves. The memory is 
coming out of a different pool.

- --The dominant buffer changed size-- Without 3D it was 8355840 bytes = 
1920 x 1088 x 4, height padded to a multiple of 64 -- the signature of a 
dumb buffer. With svga it is 8294400 = 1920 x 1080 x 4, exactly the 
screen, no padding.

So the configuration I reported was not exercising the svga driver at 
all, which was the question in my previous mail: the leak I measured was 
on the dumb-buffer/kms_swrast path, not through gallium svga.

-- About the patch:

I did build it, to be able to test properly: staging/26.1 at 2ed36c6 
("svga: Pass buffer handle for fd handles for resource_from_handle()", 
the backport of b460cff2 from your MR 43386). Verified it was actually 
loaded.. the version string reads "Mesa 26.1.6 (git-2ed36c6b5d)" and the 
vmw_winsys_to_dma_buffer symbol is present.

I have not been able to give it a meaningful before/after, because in 
the configuration where svga is in use the leak is already absent with 
the unpatched driver. I am not claiming the patch is unnecessary -- I am 
saying my machine no longer reproduces the problem it fixes.

If it helps, I can put the guest back on 3D-disabled and measure there 
with and without the patched build. Given the above I suspect it would 
show nothing, since svga is not loaded in that configuration, but say 
the word and I will run it.

-- One correction to something I nearly reported:

While switching, plasmashell started segfaulting on "dmabuf import 
failed to mmap". I was close to reporting that as a second driver bug. 
It was not: I had left LIBGL_ALWAYS_SOFTWARE=1 in place, which 
plasmashell honours but kwin does not (it goes through EGL). That left 
the compositor on svga and a client on llvmpipe trying to CPU-map a 
guest-backed buffer. With both on the same driver it is gone: 18 hours, 
zero occurrences.

The one thing that does look like a real bug is on the KDE side, not 
yours: the failed mmap leads to SIGSEGV (si_code = SEGV_MAPERR) rather 
than a blank thumbnail. I will report that to them separately.

-- Environment:

     Guest:      CachyOS (Arch-based), kernel 7.1.6-1-cachyos
     Host:       VMware Workstation on Windows, AMD Ryzen 9 7950X
     Driver:     vmwgfx, VMware SVGA II, 3D acceleration now ENABLED
     Compositor: KWin 6.7.4, Plasma Wayland, 3 x 1920x1080 @ 60 Hz
     mesa:       26.1.6-arch3.1
     max mob size: 1048576 KiB   (was 262144 KiB with 3D disabled)


Happy to run anything specific, on either configuration.


Regards,

Jellis Onsea
AccessWeb

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

[Maaz Mombasawala]

That is good to know. Do you still see a memory leak with 3D off?

-- 
Maaz Mombasawala <maaz.mombasawala@broadcom.com>

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

[Jellis Onsea | AccessWeb]

Hi Maaz, Zack,

Yes, it does, and I have to correct my message of 8 August as well.

-- Short answer

With 3D disabled again, kernel 7.1.8, stock mesa 26.1.6-arch3.1. Object
counts from vmwgfx_gem_info, sampled every 15 minutes:

   2026-08-15 14:22 - 23:53      idle, 9.5 h     370 ->  370 objects
   2026-08-15 23:53 - 16 01:08   in use          370 ->  772 objects
   2026-08-16 03:54 - 13:53      idle, 9.8 h    1274 -> 1274 objects
   2026-08-16 13:55 - 17:57      working day    1274 -> 2387 objects

Both idle windows are identical in every single sample: 39 and 40 
consecutive samples with the same object count and the same pool 
figures. Not approximately flat - identical. Nothing accumulates while 
the machine sits there, and nothing is handed back either.

I lead with counts rather than volume because of the caveat in my first 
mail: the summed object sizes exceed physical RAM, so I do not trust the 
totals. For what it is worth, the pools moved 2.16 -> 4.57 GB and 6.73
-> 13.85 GB across those two active windows.

-- This confirms my original report rather than adding to it:

The second window was a browser video call, with no RDP session
involved. In some of my later messages I linked the heavy phases to RDP,
because that was the heaviest thing running here. That was my own
mistake: my first report already said it plainly - "a browser window
with a looping CSS animation makes it measurable within minutes.
Opening and closing 32 windows produced no growth at all, so it is the
continuous rendering that drives it." The idle-versus-active split I
described then is exactly what these four windows show.

-- Correction to my message of 8 August:

I wrote that enabling 3D acceleration made the leak go away. That was
based on two svga sessions of 15.6 and 18.2 hours, and it does not
survive a longer measurement.

The problem was the length of those sessions, not the pools - I did
report both, and mob_ttm was already moving in that table. But at 18.2
hours it stood at 0.555 GB. That same boot ran on for 115.5 hours in
total, and by the end mob_ttm was at 15.15 GB.

For reference, the two pools swap roles with the configuration:

     3D off (llvmpipe)   system_ttm grows,  mob_ttm flat at 0.023 GB
     3D on  (svga)       system_ttm flat,   mob_ttm 0.27 -> 15.15 GB

Per boot, both pools added together:

   boot            hours  kernel  3D    sys+mob     objects
   2026-08-02 16:02   7.8   7.1.5  off  +1355 MB/h   753 -> 2184
   2026-08-03 04:33  34.8   7.1.5  off  +1367 MB/h    23 -> 8211
   2026-08-04 15:34  33.1   7.1.6  off   +989 MB/h    31 -> 5586
   2026-08-06 00:56  25.7   7.1.6  off   +667 MB/h    49 -> 2680
   2026-08-07 02:45  15.6   7.1.6  on      +5 MB/h    85 ->  244
   2026-08-07 18:32 115.5   7.1.6  on    +161 MB/h  1357 -> 9128
   2026-08-12 14:20  62.9   7.1.8  on     +30 MB/h  1405 -> 4418
   2026-08-15 12:03  29.6   7.1.8  off   +442 MB/h    30 -> 2236

The 2026-08-07 18:32 row is the one I got wrong. I reported +22 MB/h
for its first 18.2 hours; over the full 115.5 hours it is +161 MB/h.
I drew a conclusion from a session that had not run long enough.

So enabling 3D reduces it substantially - roughly a factor 3 to 30
depending on the session - but it does not remove it. The per-boot
averages also flatten something that is not gradual: long flat
stretches, then a jump inside a single 15-minute sample.

-- The kernel changed twice and I did not mention it:

7.1.5 -> 7.1.6 on 4 August, 7.1.6 -> 7.1.8 on 12 August, each taking
effect at the boot immediately after. Since vmwgfx is a kernel module I
should have said so at the time. Mesa stayed at 3:26.1.6-1 throughout,
so that is not a variable.

I do not think it explains anything - 7.1.8 with 3D off leaks harder
than 7.1.5 did - but it belongs in the data.

-- The patch:

Still built and still verified here:

     /usr/lib/libgallium-26.1.6-arch3.1.so   vmw_winsys_to_dma_buffer absent
     my staging/26.1 build at 2ed36c6        vmw_winsys_to_dma_buffer 
present
                                             "Mesa 26.1.6 (git-2ed36c6b5d)"

Arch has not shipped a mesa containing it; 3:26.1.6-1 is still the
current package here, so the fix has not reached this machine through
the distribution.

In the 3D-off configuration llvmpipe is in use and the buffers are dumb
buffers of 1920x1088x4, so I would not expect gallium svga to be
involved at all. If the mechanism Zack described - prime exports with no
deref/destroy ioctl, so gem_close does nothing - also applies on the
dumb-buffer path, that would explain why this configuration keeps
leaking while the mesa-side fix sits in svga.

I can run any of these, whichever is most useful to you. All four are
set up here, so it is a matter of you saying which:

   1. the patched build with 3D OFF, in the current configuration. This
      is the quickest - the build is in place and it takes a re-login.
      I expect it to change nothing, since svga is not loaded here, but
      that is worth establishing rather than assuming.
   2. the patched build with 3D ON, 48 hours or more, against the
      +161 MB/h baseline above. Needs the VM powered down to change the
      host setting, so give me a day for it.
   3. stock Arch kernel instead of the CachyOS one. Arch currently ships
      linux 7.1.8.arch1-3, which is the same version as the CachyOS
      7.1.8 I am running, so that isolates the patch set rather than the
      version. I offered a vanilla kernel in my first mail and never did
      it; it installs alongside the current one, so it is low risk here.
   4. any instrumentation you want, on either configuration - extra
      debugfs reads, a debug patch, different sampling.

Say which and I will run it.

-- One correction on the plasmashell crash:

In my 8 August mail I said the dmabuf import crash looked like a KDE bug
and that I would report it to them. That was wrong. The message comes
from libgallium, not from any KDE or Qt library, and the faulting thread
is an llvmpipe rasteriser thread. It matches mesa issue #6438, which is
still open. I will add my reproduction there instead.

Regards,

Jellis Onsea
AccessWeb

Op 13-08-2026 om 23:12 schreef Maaz Mombasawala:
> That is good to know. Do you still see a memory leak with 3D off?
> 

-- 
Met vriendelijke groeten,
AccessWeb ICT Solutions
AccessWeb.
	
ONSEA Jellis
AccessWeb ICT Solutions
Europaplein 29/7
3630 Maasmechelen
Tel BE +32 470 96 43 15 <tel:+32470964315>
Tel NL +31 6 492 757 98 <tel:+31649275798>
E-mail jellis@accessweb.be <mailto:jellis@accessweb.be>

Indien u een SLA-contract heeft, gelieve alle communicatie te voeren met
het e-mailadres gekoppeld aan uw SLA. Dit verzekert de correcte en
tijdige opvolging van uw vraag.

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

[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.

-- 
Maaz Mombasawala <maaz.mombasawala@broadcom.com>

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

[Jellis Onsea | AccessWeb]

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.
> 

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

[Maaz Mombasawala]

For the 3D-enabled case, could you try with mesa 26.1.8 or 26.2.1, both of which contain my fix.
Also if you could try the patch I just submitted on dri-devel - drm/vmwgfx: Return gem fd handle for scanout buffers.
If you still see issues with these patches, let me know.

As for the 3D disabled case, I can see issues on my local machine and am working on a fix.

PS - Your emails are overly verbose and narrative, could you include only the actual problems you are facing.
If you're using an llm to write these, please make them more terse and human readable. Thanks.

-- 
Maaz Mombasawala <maaz.mombasawala@broadcom.com>