On Sun, Feb 01, 2026 at 05:59:56PM +0800, Shenghao Yang wrote:
> gud_plane_atomic_update() currently handles both crtc state and
> framebuffer updates - the complexity has led to a few accidental
> NULL pointer dereferences.
>
> Commit dc2d5ddb193e ("drm/gud: fix NULL fb and crtc dereferences
> on USB disconnect") [1] fixed an earlier dereference but planes
> can also be disabled in non-hotplug paths (e.g. display disables
> via the desktop environment). The drm_dev_enter() call would not
> cause an early return in those and subsequently oops on
> dereferencing crtc:
>
> BUG: kernel NULL pointer dereference, address: 00000000000005c8
> CPU: 6 UID: 1000 PID: 3473 Comm: kwin_wayland Not tainted
> 6.18.2-200.vanilla.gud.fc42.x86_64 #1 PREEMPT(lazy)
> RIP: 0010:gud_plane_atomic_update+0x148/0x470 [gud]
> <TASK>
> drm_atomic_helper_commit_planes+0x28e/0x310
> drm_atomic_helper_commit_tail+0x2a/0x70
> commit_tail+0xf1/0x150
> drm_atomic_helper_commit+0x13c/0x180
> drm_atomic_commit+0xb1/0xe0
> info ? __pfx___drm_printfn_info+0x10/0x10
> drm_mode_atomic_ioctl+0x70f/0x7c0
> ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> drm_ioctl_kernel+0xae/0x100
> drm_ioctl+0x2a8/0x550
> ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> __x64_sys_ioctl+0x97/0xe0
> do_syscall_64+0x7e/0x7f0
> ? __ct_user_enter+0x56/0xd0
> ? do_syscall_64+0x158/0x7f0
> ? __ct_user_enter+0x56/0xd0
> ? do_syscall_64+0x158/0x7f0
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> Split out crtc handling from gud_plane_atomic_update() into
> atomic_enable() and atomic_disable() functions to delegate
> crtc state transitioning work to the DRM helpers.
>
> To preserve the gud state commit sequence [2], switch to
> the runtime PM version of drm_atomic_helper_commit_tail() which
> ensures that crtcs are enabled (hence sending the
> GUD_REQ_SET_CONTROLLER_ENABLE and GUD_REQ_SET_DISPLAY_ENABLE
> requests) before a framebuffer update is sent.
>
> [1] https://lore.kernel.org/all/[email protected]/
> [2] https://github.com/notro/gud/wiki/GUD-Protocol#display-state
>
> Cc: <[email protected]> # won't apply cleanly on 6.18.x
Why are you adding this?
I suspect it's because checkpatch complains that commits with BUG: in
the commit message should be CC'd to stable. (Although, I can't trigger
that warning now. Weird).
If a patch doesn't apply, then the stable scripts aren't going to apply
it. It's not necessary to tell the scripts not to try. To me the
"noautosel" basically means that it's important to not backport the
patch. Maybe the API has changed so backporting it will cause a subtle
breakage.
Are you planning to manually backport it? If so, you could CC stable
and then when you get the email that it doesn't apply, then you can do
the manual backport. Or you could ignore it.
Or if you think it's not worth backporting, you could explain why.
Cc: <[email protected]> # too risky for low benefit
regards,
dan carpenter
