linux-stable.git/drivers/gpu/drm/drm_fops.c, branch linux-4.9.y

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

2019-05-31T13:48:31+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: set FMODE_UNSIGNED_OFFSET for drm files

2018-06-13T14:16:41+00:00

commit 76ef6b28ea4f81c3d511866a9b31392caa833126 upstream.

Since we have the ttm and gem vma managers using a subset
of the file address space for objects, and these start at
0x100000000 they will overflow the new mmap checks.

I've checked all the mmap routines I could see for any
bad behaviour but overall most people use GEM/TTM VMA
managers even the legacy drivers have a hashtable.

Reported-and-Tested-by: Arthur Marsh (amarsh04 on #radeon)
Fixes: be83bbf8068 (mmap: introduce sane default mmap limits)
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm: reference count event->completion

2017-03-30T07:41:28+00:00

commit 24835e442f289813aa568d142a755672a740503c upstream.

When writing the generic nonblocking commit code I assumed that
through clever lifetime management I can assure that the completion
(stored in drm_crtc_commit) only gets freed after it is completed. And
that worked.

I also wanted to make nonblocking helpers resilient against driver
bugs, by having timeouts everywhere. And that worked too.

Unfortunately taking boths things together results in oopses :( Well,
at least sometimes: What seems to happen is that the drm event hangs
around forever stuck in limbo land. The nonblocking helpers eventually
time out, move on and release it. Now the bug I tested all this
against is drivers that just entirely fail to deliver the vblank
events like they should, and in those cases the event is simply
leaked. But what seems to happen, at least sometimes, on i915 is that
the event is set up correctly, but somohow the vblank fails to fire in
time. Which means the event isn't leaked, it's still there waiting for
eventually a vblank to fire. That tends to happen when re-enabling the
pipe, and then the trap springs and the kernel oopses.

The correct fix here is simply to refcount the crtc commit to make
sure that the event sticks around even for drivers which only
sometimes fail to deliver vblanks for some arbitrary reasons. Since
crtc commits are already refcounted that's easy to do.

References: https://bugs.freedesktop.org/show_bug.cgi?id=96781
Cc: Jim Rees 
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Jani Nikula 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20161221102331.31033-1-daniel.vetter@ffwll.ch
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

drm: remove redundant drm_file->uid

2016-09-19T09:21:42+00:00

Each DRM file-context caches the EUID of the process that opened the file.
It is used exclusively for debugging purposes in /proc/dri/ and friends.

Note, however, that we can already fetch the EUID from
priv->pid->task->creds. The pointer-chasing will not hurt us, since it is
only about debugging, anyway.

Since we already are in an rcu-read-side, we can use __task_cred() rather
than task_cred_xxx().

Signed-off-by: David Herrmann 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20160901124837.680-2-dh.herrmann@gmail.com

drm: Used DRM_LEGACY for all legacy functions

2016-08-08T08:05:23+00:00

Except for nouveau, only legacy drivers need this really. And nouveau
is already marked up with DRIVER_KMS_LEGACY_CONTEXT as the special
case.

I've tried to be careful to leave everything related to modeset still
using the DRIVER_MODESET flag. Otherwise it's a direct replacement of
!DRIVER_MODESET with DRIVER_LEGACY checks. Also helps readability
since fewer negative checks overall.

Reviewed-by: David Herrmann 
Reviewed-by: Frank Binns 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1470251470-30830-2-git-send-email-daniel.vetter@ffwll.ch

drm: Clean up drm_crtc.h

2016-06-21T19:43:28+00:00

- Group declarations for separate files (drm_bridge.c, drm_edid.c)
- Move declarations only used within drm.ko to drm_crtc_internal.h
- drm_property_type_valid to drm_crtc.c, its only callsite

Reviewed-by: Chris Wilson 
Reviewed-by: Emil Velikov 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-2-git-send-email-daniel.vetter@ffwll.ch

drm: Move authmagic cleanup into drm_master_release

2016-06-20T20:02:01+00:00

It's related, and soon authmagic will also use the master_mutex.

There is an ever-so-slightly semantic change here:
- authmagic will only be cleaned up for primary_client drm_minors. But
  it's impossible to create authmagic on render/control nodes, so this
  is fine.
- The cleanup is moved down a bit in the release processing. Doesn't
  matter at all since authmagic is purely internal logic used by the
  core ioctl access checks, and when we're in a file's release
  callback no one can do ioctls any more.

v2: Rebased.

Cc: Chris Wilson 
Reviewed-by: Chris Wilson  (v1)
Reviewed-by: Emil Velikov 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-3-git-send-email-daniel.vetter@ffwll.ch

drm: Extract drm_master_relase

2016-06-16T08:17:58+00:00

Like with drm_master_open protect it with a check for primary_client
to make it clear that this can't happen on render/control nodes.

Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1465930269-7883-7-git-send-email-daniel.vetter@ffwll.ch

drm: Extract drm_master_open

2016-06-16T08:17:42+00:00

And pull out the primary_client check to make it really obvious that
this can't happen on control/render nodes. Bonus that we can avoid the
master lock in this case.

v2: Don't leak locks on error path (and simplify control flow while
at it), reported by Julia.

Cc: Julia Lawall 
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1465930269-7883-6-git-send-email-daniel.vetter@ffwll.ch

drm: Move master functions into drm_auth.c

2016-06-16T08:17:23+00:00

For modern drivers pretty much the only thing drm_master does is
handling authentication for the primary/legacy drm_minor node. Instead
of having it all over drm files, move it all together into drm_auth.c.

This patch just does code-motion, follow up patches will also extract
the master logic from file open&release paths.

Reviewed-by: Chris Wilson Mchris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1465930269-7883-5-git-send-email-daniel.vetter@ffwll.ch