cc'ing dri-devel, which apparently got lost somehow
Am 07.11.25 um 08:02 schrieb Thomas Zimmermann:
Hi
Am 07.11.25 um 06:06 schrieb Zack Rusin:
On Tue, Nov 4, 2025 at 5:36 AM Thomas Zimmermann
<[email protected]> wrote:
Set struct drm_framebuffer.obj[0] to the allocated GEM buffer object
for surface framebuffers. Avoids a NULL-pointer deref in the client's
vmap helpers.
[ 22.640191] Console: switching to colour frame buffer device 160x50
[ 22.641788] Oops: general protection fault, probably for
non-canonical address 0xdffffc000000001f: 0000 [#1] SMP KASAN NOPTI
[ 22.641795] KASAN: null-ptr-deref in range
[0x00000000000000f8-0x00000000000000ff]
[...]
[ 22.641809] Hardware name: VMware, Inc. VMware20,1/440BX Desktop
Reference Platform, BIOS VMW201.00V.24928539.B64.2508260915
08/26/2025
[ 22.641812] Workqueue: events drm_fb_helper_damage_work
[ 22.641824] RIP: 0010:drm_gem_lock+0x25/0x50
[ 22.641831] Code: 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 b8
00 00 00 00 00 fc ff df 53 48 89 fb 48 81 c7 f8 00 00 00 48 89 fa 48
c1 ea 03 <80> 3c 02 00 75 0f 48 8b bb f8 00 00 00 31 f6 5b e9 16
2e 15
01 e8
[...]
[ 22.641889] Call Trace:
[ 22.641891] <TASK>
[ 22.641894] drm_client_buffer_vmap_local+0x78/0x140
[ 22.641903] drm_fbdev_ttm_helper_fb_dirty+0x20c/0x510
[drm_ttm_helper]
[ 22.641913] ? __pfx_drm_fbdev_ttm_helper_fb_dirty+0x10/0x10
[drm_ttm_helper]
[ 22.641918] ? __raw_spin_lock_irqsave+0x8c/0xf0
[ 22.641924] ? __pfx___raw_spin_lock_irqsave+0x10/0x10
[ 22.641928] ? __pfx_mutex_lock+0x10/0x10
[ 22.641936] drm_fb_helper_fb_dirty+0x29a/0x5e0
[ 22.641942] ? __pfx_drm_fb_helper_fb_dirty+0x10/0x10
[...]
Signed-off-by: Thomas Zimmermann <[email protected]>
Fixes: ea39f2e66e61 ("drm/client: Deprecate struct
drm_client_buffer.gem")
Reported-by: Ian Forbes <[email protected]>
Closes:
https://lore.kernel.org/dri-devel/cao6mgtjg8pirislomjqrbdutbsc0wkqx67tezwa9qwogrzc...@mail.gmail.com/
Cc: Thomas Zimmermann <[email protected]>
Cc: Jocelyn Falempe <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Simona Vetter <[email protected]>
Cc: [email protected]
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 54ea1b513950..d32ce1cb579e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -553,6 +553,9 @@ static int
vmw_kms_new_framebuffer_surface(struct vmw_private *dev_priv,
memcpy(&vfbs->uo, uo, sizeof(vfbs->uo));
vmw_user_object_ref(&vfbs->uo);
+ if (vfbs->uo.buffer)
+ vfbs->base.base.obj[0] = &vfbs->uo.buffer->tbo.base;
+
*out = &vfbs->base;
ret = drm_framebuffer_init(dev, &vfbs->base.base,
--
2.51.1
Thanks Thomas, that looks good. We'll have to figure out how to make
sure there's always a gem buffer backing those surfaces.
That might not be much of a problem in practice. The commit that the
Fixes tag points to only streamlines some of the code around
drm_client_dev. But it always relied on having a GEM buffer allocated.
So AFAICT nothing really has changed; except that drm_client now looks
at the standard place for the GEM object.
Would you like me to push it to drm-misc-next, or do you want to do it?
I'll push it out in a bit.
Best regards
Thomas
Reviewed-by: Zack Rusin <[email protected]>
z
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
