Public bug reported:
Release of Ubuntu: Ubuntu 26.04.1 LTS (resolute)
Version of the package: kwin-wayland 4:6.6.6-0ubuntu0.1 (also kwin-
common 4:6.6.6-0ubuntu0.1)
Other relevant versions:
- Kernel: 7.0.0-30-generic
- Mesa: 26.2.5~kisak1~r (ppa:kisak/kisak-mesa; mesa-libgallium,
libgl1-mesa-dri, libegl-mesa0). Also seen with Ubuntu's Mesa 26.0.8.
Description:
The Ubuntu patch debian/patches/fix-drm-open-fallback-to-logind-fd.patch
(added in 4:6.6.3-0ubuntu3 for LP: #2147233) changes
DrmDevice::openWithAuthentication() in src/core/drmdevice.cpp. If the
direct ::open() of /dev/dri/card* fails, it uses fcntl(authenticatedFd,
F_DUPFD_CLOEXEC, 0) on the logind fd instead. The resulting fd is passed
to gbm_create_device(), so Mesa (iris) renders on the same open file
description as kwin's KMS code (DrmGpu::m_fd).
That breaks a basic DRM rule: GEM handles belong to the open file and
are not refcounted. Mesa says so in
src/gallium/drivers/iris/iris_bufmgr.c:
/* Handles to buffer objects belong to the device fd and are not
* reference counted by the kernel. If the same fd is used by
* multiple parties [...] ownership of those handles is shared by
* those independent parties.
*
* Don't do this! Ensure that each library/bufmgr has its own device
* fd so that its namespace does not clash with another.
*/
What happens when the fallback is used:
- DrmGpu::importBuffer() (src/backends/drm/drm_gpu.cpp) calls
drmPrimeFDToHandle() on the KMS fd for direct scanout, tries
drmModeAddFB2WithModifiers(), and always calls drmCloseBufferHandle()
afterwards.
- If the dmabuf's BO already has a handle in this file because Mesa owns or
imported it, drmPrimeFDToHandle() returns Mesa's handle, and kwin then closes
it behind Mesa's back.
- The kernel reuses the handle number for a new BO. Mesa keeps using the old
number, so it binds and renders with the wrong object.
Result: coloured garbage on the panel and windows right after login, GPU
hangs, and a kwin crash that takes down apps such as Firefox ("Exiting
due to channel error"). Typical backtrace: glFenceSync -> tc_flush ->
iris_draw_vbo -> iris_upload_dirty_render_state -> stream_state with a
NULL resource, after a failed VM_BIND.
When it triggers: for any user who is not in the "video" group (the
Ubuntu default). In that case access to /dev/dri/card* comes only from
the logind uaccess ACL, which is sometimes not yet set when kwin_wayland
starts at login. After kwin's automatic restart following the first
crash, the ACL is present, the direct open succeeds, and the session is
stable. This is why reporters see "it gets better after the first
crash".
Affected system: Lenovo ThinkPad E16 Gen 4, Intel Core Ultra 7 355
(Panther Lake, xe driver), Kubuntu 26.04.1, kwin 4:6.6.6-0ubuntu0.1,
kernel 7.0.0-30-generic, Mesa 26.0.8 (Ubuntu) and 26.2.5 (kisak PPA).
The xe driver makes the problem very visible because it validates
caching modes at VM_BIND. Other drivers may corrupt silently.
Evidence (kernel with drm.debug=0x2):
[drm:xe_vm_bind_ioctl_validate_bo [xe]] Ioctl argument check failed at
drivers/gpu/drm/xe/xe_vm.c:3580: coh_mode == XE_COH_NONE && bo->cpu_caching ==
DRM_XE_GEM_CPU_CACHING_WB
(Mesa binds its WC buffer by a handle that now refers to another,
WB-cached BO; kwin crashes right after)
Further evidence:
- With a Mesa build that logs the DRM fds of the process at screen creation,
every /dev/dri/card1 fd at the first kwin start after boot, including the
logind fd, has the same drm-client-id (shared file). After the crash and
automatic restart, the logind fd has its own drm-client-id, separate from
Mesa's.
- xe devcoredumps of GPU hangs in that session name "systemd-logind" as the
process. That is the opener of the file, although the hung context is kwin's.
- Adding the user to the video and render groups ("sudo usermod -aG
video,render $USER", then reboot) makes the direct open always succeed and
fixes the problem completely.
- Long-term result of that workaround (2026-10-25 to 2026-10-29): 14 boots,
many suspend/resume cycles, normal daily use. No GPU resets, no kwin crashes,
no corruption after login, no failed VM_BIND. Before, most boots showed the
problem within minutes of login. Kernel, Mesa and kwin versions were unchanged,
so the group membership (that is, whether the fallback path is taken) is the
only difference.
Steps to reproduce:
1. Panther Lake (xe) laptop, Kubuntu 26.04.1, user not in the "video" group.
2. Boot, log in to Plasma Wayland and use the desktop normally (Firefox,
Konsole).
3. Within minutes you see flashing garbage, GPU hangs and/or a kwin crash. This
happens often, but not on every boot, because it is a race with the ACL setup.
Expected: kwin never shares its KMS DRM file with Mesa.
Suggested fix: drop the dup() fallback for the GBM/EGL device, or limit
it to the greeter case it was written for. Instead, retry the direct
open, for example after the session's device ACL appears, or fail as
upstream does. If a fallback is unavoidable, kwin must not close GEM
handles on the KMS fd that Mesa may share; in practice that means it
must not use a shared fd at all.
Related bugs:
- LP: #2147233 (origin of the patch)
- LP: #2168035 and KDE bug 526118 (same symptoms on a ThinkPad X9-15p, Panther
Lake; not reproducible on Fedora, which does not carry this patch)
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2172530
Title:
kwin: fix-drm-open-fallback-to-logind-fd.patch makes KMS and Mesa
share one GEM handle namespace -> rendering corruption, GPU hangs and
kwin crashes after login
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172530/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
