[PATCH 06/16] drm: Move master pointer from drm_minor to drm_device

[Chris Wilson]

On Fri, Jun 17, 2016 at 09:33:24AM +0200, Daniel Vetter wrote:
> 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 <thellstrom at vmware.com>
>   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.
> 
> Cc: Julia Lawall <julia.lawall at lip6.fr>
> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>

Ok, I understand now why drm_new_set_master appears backwards to me. It
really is creating a new master that fpriv inherits (just like fpriv
inherits the existing master otherwise).

Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
-chris

-- 
Chris Wilson, Intel Open Source Technology Centre