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@xxxxxxxxxx> > 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@xxxxxxx> > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> -chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
