linux/drivers/gpu/drm/drm_auth.c, branch v4.9

drm: Used DRM_LEGACY for all legacy functions

2016-08-08T08:05:23Z

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: document drm_auth.c

2016-06-21T20:10:55Z

Also extract drm_auth.h for nicer grouping. v2: Nuke the other comments since they don't really explain a lot, and within the drm core we generally only document functions exported to drivers: The main audience for these docs are driver writers. v3: Limit the exposure of drm_master internals by only including drm_auth.h where it is neede (Chris). v4: Spelling polish (Emil). Cc: Chris Wilson Reviewed-by: Chris Wilson Reviewed-by: Emil Velikov Signed-off-by: Daniel Vetter

drm: Clear up master tracking booleans

2016-06-21T19:58:29Z

- is_master can be removed, we can compute this by checking allowed_master (which really just tracks whether a master struct has been allocated for this fpriv in either open or set_master), and whether the fpriv is the current master on the device. - that frees up is_master as a good replacement name for allowed_master. With that it's clear that it tracks whether the fpriv is a master (with possibly clients attached to it and authenticated against it), and that one of those fprivs with is_master set is the current master. v2: Fix kerneldoc for is_master (Emil). Cc: Chris Wilson Cc: Thomas Hellstrom Reviewed-by: Chris Wilson Reviewed-by: Emil Velikov Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-10-git-send-email-daniel.vetter@ffwll.ch

drm: Extract drm_is_current_master

2016-06-21T19:58:12Z

Just rolling out a bit of abstraction to be able to clean up the master logic in the next step. Cc: Chris Wilson Cc: Thomas Hellstrom Reviewed-by: Chris Wilson Reviewed-by: Emil Velikov Signed-off-by: Daniel Vetter

drm: Refactor drop/set master code a bit

2016-06-21T19:56:28Z

File open/set_maseter ioctl and file close/drop_master ioctl share the same master handling code. Extract it. Note that vmwgfx's master_set callback needs to know whether the master is a new one or has been used already, so thread this through. On the close/drop side a similar parameter existed, but wasnt used. Drop it to simplify the flow. v2: Try to make it not leak so much (Emil). v3: Send out the right version ... Cc: Emil Velikov Cc: Chris Wilson Cc: Thomas Hellstrom Reviewed-by: Chris Wilson Reviewed-by: Emil Velikov Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1466511638-9885-1-git-send-email-daniel.vetter@ffwll.ch

drm: Move master pointer from drm_minor to drm_device

2016-06-21T19:43:24Z

There can only be one current master, and it's for the overall device. Render/control minors don't support master-based auth at all. This simplifies the master logic a lot, at least in my eyes: All these additional pointer chases are just confusing. While doing the conversion I spotted some locking fail: - drm_lock/drm_auth check dev->master without holding the master_mutex. This is fallout from commit c996fd0b956450563454e7ccc97a82ca31f9d043 Author: Thomas Hellstrom Date: Tue Feb 25 19:57:44 2014 +0100 drm: Protect the master management with a drm_device::master_mutex v3 but I honestly don't care one bit about those old legacy drivers using this. - debugfs name info should just grab master_mutex. - And the fbdev helper looked at it to figure out whether someone is using KMS. We just need a consistent value, so READ_ONCE. Aside: We should probably check if anyone has opened a control node too, but I guess current userspace doesn't really do that yet. v2: Balance locking, reported by Julia. v3: Rebase on top of Chris' oops fixes. Cc: Julia Lawall Cc: Chris Wilson Reviewed-by: Chris Wilson (v2) Reviewed-by: Emil Velikov (v2) Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-1-git-send-email-daniel.vetter@ffwll.ch

drm: Protect authmagic with master_mutex

2016-06-20T20:02:09Z

Simplifies cleanup, and there's no reason drivers should ever care about authmagic at all - it's all handled in the core. And with that, Ladies and Gentlemen, it's time to pop the champagen and celebrate: dev->struct_mutex is now officially gone from modern drivers, and if a driver is using gem_free_object_unlocked and doesn't do anything else silly it's positively impossible to ever touch dev->struct_mutex at runtime, anywhere. Well except for the mutex_init on driver load ;-) v2: Rebased. Cc: Chris Wilson (v1) Reviewed-by: Chris Wilson (v1) Reviewed-by: Emil Velikov Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-4-git-send-email-daniel.vetter@ffwll.ch

drm: Move authmagic cleanup into drm_master_release

2016-06-20T20:02:01Z

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: Only do the hw.lock cleanup in master_relase for !MODESET

2016-06-20T20:01:29Z

Another place gone where modern drivers could have hit dev->struct_mutex. To avoid too deeply nesting control flow rework it a bit. v2: Review from Chris: - remove spurious newline. - fix file_priv->master like for the !file_priv->is_master case. Cc: Chris Wilson Reviewed-by: Chris Wilson Reviewed-by: Emil Velikov Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-2-git-send-email-daniel.vetter@ffwll.ch

drm: Extract drm_master_relase

2016-06-16T08:17:58Z

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