x11bridge: tolerate redundant GEM close for multi-plane DRI3 buffers by aford173 · Pull Request #231 · AsahiLinux/muvm

aford173 · 2026-06-29T14:43:27Z

A DRI3 PixmapFromBuffers request for a multi-plane buffer (or any buffer whose planes share one backing object) passes several dma-buf fds that all resolve to the same virtgpu GEM handle, because drm_prime_fd_to_handle deduplicates imports of the same underlying object. vgpu_id_from_prime creates one GemHandleFinalizer per fd, so once the request has been forwarded the bridge calls drm_gem_close on that handle once per fd. The first close frees the handle; each subsequent close of the now-invalid handle returns EINVAL (ENOENT on some drivers), which propagated out of process_socket and tore down the entire X11 client connection.

This is easy to hit with the Intel iris native context, which hands DRI3 a multi-plane (CCS-aux) buffer: glmark2 and other GL clients died with "XIO: fatal IO error 95 ... after 38 requests" the moment the first frame's pixmap was finalized.

Treat EINVAL/ENOENT from the redundant close as success: the handle is already gone, which is exactly the intended outcome.

Tested on an Intel Raptor Lake-U iGPU (8086:a721) with the iris native context, with the host iGPU bound to both the i915 and the xe kernel driver: before this change every GL client died with the XIO 95 above; after it, glmark2 runs to completion on both drivers (GL_RENDERER "Mesa Intel(R) Graphics (RPL-U)", clean exit, no finalizer/XIO errors). The fix is host-driver-independent, as the offending close is against the guest virtio-gpu device.

teohhanhui · 2026-06-30T16:53:07Z

CI failures seem unrelated. /cc @slp

@aford173 You need to fix the commit message to include the required Signed-off-by: ... signature.

A DRI3 PixmapFromBuffers for a multi-plane buffer (or any buffer whose planes share one backing object) passes several dma-buf fds that all resolve to the same virtgpu GEM handle, since drm_prime_fd_to_handle deduplicates imports of the same object. vgpu_id_from_prime creates one GemHandleFinalizer per fd, so the bridge calls drm_gem_close on that handle once per fd. The first close frees it; each redundant close returns EINVAL (ENOENT on some drivers), which propagated out of process_socket and tore down the whole X11 client. Refcount the live finalizers per handle: vgpu_id_from_prime increments on import and finalize decrements, closing only when the last one runs. This makes the redundant close impossible rather than swallowing its error, so genuine drm_gem_close errors are still propagated. The Intel iris native context hands DRI3 a multi-plane CCS-aux buffer and was affected: every GL client (glmark2 and others) died with "XIO: fatal IO error 95" on the first frame, now they run to completion. Tested on an Intel Raptor Lake-U iGPU (8086:a721), host iGPU bound to both i915 and xe. AMD (Strix Point) and Mali (MediaTek MT8196) do not pass multi-plane buffers this way and were unaffected. The fix is host-driver-independent, as the offending close is against the guest virtio-gpu device. Signed-off-by: Adam Ford <adam.ford@anodize.com>

aford173 · 2026-06-30T16:57:08Z

CI failures seem unrelated. /cc @slp

@aford173 You need to fix the commit message to include the required Signed-off-by: ... signature.

Thanks for the reminder. Sorry about that. I added it now.

aford173 requested review from WhatAmISupposedToPutHere, alyssarosenzweig, slp and teohhanhui as code owners June 29, 2026 14:43

teohhanhui reviewed Jun 29, 2026

View reviewed changes