kernel/linux.git/drivers/gpu/drm/vgem, branch v5.10.7

drm/vgem: Use devm_drm_dev_alloc

2020-09-11T08:47:19+00:00

This means we also need to slightly restructure the exit code, so that final cleanup of the drm_device is triggered by unregistering the platform device. Note that devres is both clean up when the driver is unbound (not the case for vgem, we don't bind), and also when unregistering the device (very much the case for vgem). Therefore we can rely on devres even though vgem isn't a proper platform device driver. This also somewhat untangles the load code, since the drm and platform device setup are no longer interleaved, but two distinct steps. v2: use devres_open/release_group so we can use devm without real hacks in the driver core or having to create an entire fake bus for testing drivers. Might want to extract this into helpers eventually, maybe as a mock_drm_dev_alloc or test_drm_dev_alloc. v3: Fix error code handling (Melissa) Cc: Melissa Wen Reviewed-by: Melissa Wen Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc: Emil Velikov Cc: Sean Paul Cc: Chris Wilson Cc: Sam Ravnborg Cc: Rob Clark Link: https://patchwork.freedesktop.org/patch/msgid/20200909120745.716178-1-daniel.vetter@ffwll.ch

drm: allow limiting the scatter list size.

2020-09-09T05:58:56+00:00

Add drm_device argument to drm_prime_pages_to_sg(), so we can call dma_max_mapping_size() to figure the segment size limit and call into __sg_alloc_table_from_pages() with the correct limit. This fixes virtio-gpu with sev. Possibly it'll fix other bugs too given that drm seems to totaly ignore segment size limits so far ... v2: place max_segment in drm driver not gem object. v3: move max_segment next to the other gem fields. v4: just use dma_max_mapping_size(). Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20200907112425.15610-2-kraxel@redhat.com

drm/vgem: add missing platform_device_unregister() in vgem_init()

2020-08-10T13:31:02+00:00

When vgem_init() get into out_put, the unregister call of vgem_device->platform is missing. So add it before return. Fixes: 363de9e7d4f6 ("drm/vgem: Use drmm_add_final_kfree") Signed-off-by: Qinglang Miao Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200810125942.186637-1-miaoqinglang@huawei.com

drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset()

2020-07-08T21:00:21+00:00

drm_gem_dumb_map_offset() now exists and does everything vgem_gem_dump_map does and *ought* to do. In particular, vgem_gem_dumb_map() was trying to reject mmapping an imported dmabuf by checking the existence of obj->filp. Unfortunately, we always allocated an obj->filp, even if unused for an imported dmabuf. Instead, the drm_gem_dumb_map_offset(), since commit 90378e589192 ("drm/gem: drm_gem_dumb_map_offset(): reject dma-buf"), uses the obj->import_attach to reject such invalid mmaps. This prevents vgem from allowing userspace mmapping the dumb handle and attempting to incorrectly fault in remote pages belonging to another device, where there may not even be a struct page. v2: Use the default drm_gem_dumb_map_offset() callback Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces") Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter Cc: # v4.13+ Link: https://patchwork.freedesktop.org/patch/msgid/20200708154911.21236-1-chris@chris-wilson.co.uk

drm/vgem: remove _unlocked suffix in drm_gem_object_put_unlocked

2020-05-19T21:31:36+00:00

Spelling out _unlocked for each and every driver is a annoying. Especially if we consider how many drivers, do not know (or need to) about the horror stories involving struct_mutex. Just drop the suffix. It makes the API cleaner. Done via the following script: __from=drm_gem_object_put_unlocked __to=drm_gem_object_put for __file in $(git grep --name-only $__from); do sed -i "s/$__from/$__to/g" $__file; done Cc: David Airlie Cc: Daniel Vetter Cc: Emil Velikov Signed-off-by: Emil Velikov Acked-by: Sam Ravnborg Reviewed-by: Daniel Vetter Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20200515095118.2743122-35-emil.l.velikov@gmail.com

drm: Garbage collect drm_dev_fini

2020-03-26T14:45:36+00:00

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:51+00:00

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:41+00:00

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:30+00:00

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:21+00:00

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