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@vmware.com Date: Tue Feb 25 19:57:44 2014 +0100
drm: Protect the master management with a drm_device::master_mutex v3but 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@lip6.fr Cc: Chris Wilson chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vetter@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@chris-wilson.co.uk -chris