linux/drivers/gpu/drm/vgem, branch v5.8

drm: Garbage collect drm_dev_fini

2020-03-26T14:45:36Z

It has become empty. Given the few users I figured not much point splitting this up. v2: Rebase over i915 changes. v3: Rebase over patch split fix. Acked-by: Sam Ravnborg Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-26-daniel.vetter@ffwll.ch

drm/vgem: Use drmm_add_final_kfree

2020-03-26T14:26:51Z

With this we can drop the final kfree from the release function. v2: After drm_dev_init/drmm_add_final_kfree we need to clean up everything through a drm_dev_put. Rework the unwind code to match that. Acked-by: Sam Ravnborg Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc: Emil Velikov Cc: Chris Wilson Cc: Sean Paul Cc: Eric Anholt Cc: Rob Clark Cc: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-14-daniel.vetter@ffwll.ch

drm/vgem: Close use-after-free race in vgem_gem_create

2020-02-06T18:04:41Z

There's two references floating around here (for the object reference, not the handle_count reference, that's a different thing): - The temporary reference held by vgem_gem_create, acquired by creating the object and released by calling drm_gem_object_put_unlocked. - The reference held by the object handle, created by drm_gem_handle_create. This one generally outlives the function, except if a 2nd thread races with a GEM_CLOSE ioctl call. So usually everything is correct, except in that race case, where the access to gem_object->size could be looking at freed data already. Which again isn't a real problem (userspace shot its feet off already with the race, we could return garbage), but maybe someone can exploit this as an information leak. Cc: Dan Carpenter Cc: Hillf Danton Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Cc: Emil Velikov Cc: Daniel Vetter Cc: Sean Paul Cc: Chris Wilson Cc: Eric Anholt Cc: Sam Ravnborg Cc: Rob Clark Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200202132133.1891846-1-daniel.vetter@ffwll.ch

dma-buf: rename reservation_object to dma_resv

2019-08-13T07:09:30Z

Be more consistent with the naming of the other DMA-buf objects. Signed-off-by: Christian König Reviewed-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/323401/

drm/vgem: drop DRM_AUTH usage from the driver

2019-08-07T15:53:21Z

The authentication can be circumvented, by design, by using the render node. From the driver POV there is no distinction between primary and render nodes, thus we can drop the token. Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Emil Velikov Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190527081741.14235-11-emil.l.velikov@gmail.com

Revert "drm/vgem: drop DRM_AUTH usage from the driver"

2019-08-07T14:45:00Z

This reverts commit e4eee93d25776da998ec2dfaabe7d2206598d26d. Mandatory review was missing from this patch. Acked-by: Maxime Ripard Acked-by: Emil Velikov Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190807142101.251400-4-sean@poorly.run

drm/vgem: drop use of drmP.h

2019-07-17T10:52:55Z

Drop use of the deprecated header drmP.h. Replace with necessary includes in the individual .c files. Signed-off-by: Sam Ravnborg Acked-by: Emil Velikov Cc: David Airlie Cc: Daniel Vetter Cc: Deepak Sharma Cc: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20190716064220.18157-13-sam@ravnborg.org

drm/vgem: Reclassify buffer creation debug message

2019-07-12T16:35:37Z

A buffer is created in response to the user ioctl, it should therefore be a plain DRM_DEBUG() message to reflect it being a user invoked response and not a driver construct. This is just to make the commonplace drm.debug=[26e] quieter when running with vgem. Signed-off-by: Chris Wilson Cc: Daniel Vetter Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190712120147.29830-1-chris@chris-wilson.co.uk

drm/vgem: drop DRM_AUTH usage from the driver

2019-06-26T14:00:40Z

The authentication can be circumvented, by design, by using the render node. From the driver POV there is no distinction between primary and render nodes, thus we can drop the token. Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Emil Velikov Link: https://patchwork.freedesktop.org/patch/msgid/20190527081741.14235-11-emil.l.velikov@gmail.com

drm/vgem: Ditch attach trickery in the fence ioctl

2019-06-21T20:20:20Z

It looks like this was done purely to get a consistent place to look up the reservation object pointer. With the drm_prime.c helper code now also setting gem_object->resv for imported objects we can just use that pointer directly, instead of first ensuring a dma-buf exists. v2: Note that I screwed up the patch ordering, hence why this needed a Fixes: tag - CI spotted the broken intermediate state. Fixes: 5eab998741c8 ("drm/vgem: Drop drm_gem_prime_export") Reviewed-by: Emil Velikov Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-49-daniel.vetter@ffwll.ch