kernel/linux.git/drivers/gpu/drm/drm_file.c, branch v5.1.10

drm: Wake up next in drm_read() chain if we are forced to putback the event

2019-05-31T13:43:58+00:00

[ Upstream commit 60b801999c48b6c1dd04e653a38e2e613664264e ] After an event is sent, we try to copy it into the user buffer of the first waiter in drm_read() and if the user buffer doesn't have enough room we put it back onto the list. However, we didn't wake up any subsequent waiter, so that event may sit on the list until either a new vblank event is sent or a new waiter appears. Rare, but in the worst case may lead to a stuck process. Testcase: igt/drm_read/short-buffer-wakeup Signed-off-by: Chris Wilson Cc: Daniel Vetter Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20170804082328.17173-1-chris@chris-wilson.co.uk Signed-off-by: Sasha Levin

drm: Fix drm_release() and device unplug

2019-03-25T05:58:05+00:00

If userspace has open fd(s) when drm_dev_unplug() is run, it will result in drm_dev_unregister() being called twice. First in drm_dev_unplug() and then later in drm_release() through the call to drm_put_dev(). Since userspace already holds a ref on drm_device through the drm_minor, it's not necessary to add extra ref counting based on no open file handles. Instead just drm_dev_put() unconditionally in drm_dev_unplug(). We now have this: - Userpace holds a ref on drm_device as long as there's open fd(s) - The driver holds a ref on drm_device as long as it's bound to the struct device When both sides are done with drm_device, it is released. Signed-off-by: Noralf Trønnes Reviewed-by: Oleksandr Andrushchenko Reviewed-by: Daniel Vetter Reviewed-by: Sean Paul Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20190208140103.28919-2-noralf@tronnes.org

Merge tag 'drm-misc-fixes-2019-02-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

2019-03-04T22:14:22+00:00

drm-misc-fixes for v5.0: - Block fb changes for async atomic updates to prevent a use after free. - Fix ID mismatch error on load in bochs. - Fix memory leak when drm_setup fails. - Fixes around handling of DRM_AUTH. Signed-off-by: Dave Airlie From: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/42113611-e2cd-6bdd-7de5-4f8ab5a0cbe6@linux.intel.com

drm: plug memory leak on drm_setup() failure

2019-02-13T17:39:47+00:00

Currently we fail to free and detach the drm_file when drm_setup() fails. Use the drm_close_helper to do address that. Signed-off-by: Emil Velikov Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190114084410.15266-2-emil.l.velikov@gmail.com

drm: factor out drm_close_helper() function

2019-02-13T17:39:32+00:00

Will be used to plug an existing memory leak. Signed-off-by: Emil Velikov Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190114084410.15266-1-emil.l.velikov@gmail.com

drm: Trivial comment grammar cleanups

2019-02-04T09:21:17+00:00

Most of these are just cases where code comments used contractions (it's, who's) where they actually mean to use a possessive pronoun (its, whose) or vice-versa. Signed-off-by: Matt Roper Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190202012326.20096-1-matthew.d.roper@intel.com

Remove 'type' argument from access_ok() function

2019-01-04T02:57:57+00:00

Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument of the user address range verification function since we got rid of the old racy i386-only code to walk page tables by hand. It existed because the original 80386 would not honor the write protect bit when in kernel mode, so you had to do COW by hand before doing any user access. But we haven't supported that in a long time, and these days the 'type' argument is a purely historical artifact. A discussion about extending 'user_access_begin()' to do the range checking resulted this patch, because there is no way we're going to move the old VERIFY_xyz interface to that model. And it's best done at the end of the merge window when I've done most of my merges, so let's just get this done once and for all. This patch was mostly done with a sed-script, with manual fix-ups for the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form. There were a couple of notable cases: - csky still had the old "verify_area()" name as an alias. - the iter_iov code had magical hardcoded knowledge of the actual values of VERIFY_{READ,WRITE} (not that they mattered, since nothing really used it) - microblaze used the type argument for a debug printout but other than those oddities this should be a total no-op patch. I tried to fix up all architectures, did fairly extensive grepping for access_ok() uses, and the changes are trivial, but I may have missed something. Any missed conversion should be trivially fixable, though. Signed-off-by: Linus Torvalds

drm: Begin an API for in-kernel clients

2018-07-10T12:51:37+00:00

This the beginning of an API for in-kernel clients. First out is a way to get a framebuffer backed by a dumb buffer. Only GEM drivers are supported. The original idea of using an exported dma-buf was dropped because it also creates an anonomous file descriptor which doesn't work when the buffer is created from a kernel thread. The easy way out is to use drm_driver.gem_prime_vmap to get the virtual address, which requires a GEM object. This excludes the vmwgfx driver which is the only non-GEM driver apart from the legacy ones. A solution for vmwgfx will have to be worked out later if it wants to support the client API which it probably will when we have a bootsplash client. Suggested-by: Daniel Vetter Signed-off-by: Noralf Trønnes Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180703160354.59955-2-noralf@tronnes.org

drm/file: Don't set master on in-kernel clients

2018-06-25T14:18:39+00:00

It only makes sense for userspace clients. Signed-off-by: Noralf Trønnes Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180618141739.48151-3-noralf@tronnes.org

drm: provide management functions for drm_file

2018-06-25T14:17:03+00:00

Rather than doing drm_file allocation/destruction right in the fops, lets provide separate helpers. This decouples drm_file management from the still-mandatory drm-fops. It prepares for use of drm_file without the fops, both by possible separate fops implementations and APIs (not that I am aware of any such plans), and more importantly from in-kernel use where no real file is available. Signed-off-by: David Herrmann Signed-off-by: Noralf Trønnes Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180618141739.48151-2-noralf@tronnes.org