All of lore.kernel.org
 help / color / mirror / Atom feed
From: Emil Velikov <emil.l.velikov@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 03/14] drm: Link directly from drm_master to drm_device
Date: Thu, 16 Jun 2016 21:04:06 +0100	[thread overview]
Message-ID: <CACvgo51iHDwz2qrHx2RZoEUHXBZyzYyYjdvKW1dBPiZFYjNmOQ@mail.gmail.com> (raw)
In-Reply-To: <20160615154549.GL1338@phenom.ffwll.local>

On 15 June 2016 at 16:45, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Jun 15, 2016 at 01:50:02PM +0100, Emil Velikov wrote:
>> On 14 June 2016 at 19:50, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> > Master-based auth only exists for the legacy/primary drm_minor, hence
>> > there can only be one per device. The goal here is to untangle the
>> > epic dereference games of minor->master and master->minor which is
>> > just massively confusing.
>> >
>> Good riddance :-)
>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>>
>> Taking this a step further, have you considered:
>>  - having the master under drm_device, then
>>  - nuking the drm_file/drm_minor one and adding drm_minor::has_master.
>> The last one will be checked before accessing drm_minor::dev::master.
>>
>> The above should work just fine, right ?
>
> We still need a pointer for the dev->master link. A later patch will
> simplify that, but entirely embedding doesn't work: drm_master must be
> free-standing, since when you drop_master all the clients authenticated
> against you will still be connected to your master. This is to make sure
> that they loose their authentication when vt switching to another X
> server. When you reacquire master with set_master, all the clients
> authenticated against that master are again considered authenticated.
>
Just to double check:

+ * Note that master structures are only relevant for the legacy/primary device
+ * nodes, hence there can only be one per device, not one per drm_minor.

In the above does "one per device" reference the "legacy/primary
device node" or the "drm_master struct" ? I was thinking about the
latter then again, reading your reply I'm not sure any more :-(

Or perhaps it is the latter but it should read "one active/associated
per device" ? In which case, yes drm_master should be standalone. Can
you please shed some light ?

Thanks
Emil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-06-16 20:04 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-14 18:50 [PATCH 00/14] Cruft removal around drm_master Daniel Vetter
2016-06-14 18:50 ` [PATCH 01/14] drm: Nuke legacy maps debugfs files Daniel Vetter
2016-06-15 11:23   ` Chris Wilson
2016-06-15 12:00   ` Emil Velikov
2016-06-14 18:50 ` [PATCH 02/14] drm: Hide hw.lock cleanup in filp->release better Daniel Vetter
2016-06-15 11:26   ` [Intel-gfx] " Chris Wilson
2016-06-15 12:10   ` Emil Velikov
2016-06-14 18:50 ` [PATCH 03/14] drm: Link directly from drm_master to drm_device Daniel Vetter
2016-06-15 11:29   ` Chris Wilson
2016-06-15 12:50   ` [Intel-gfx] " Emil Velikov
2016-06-15 15:45     ` Daniel Vetter
2016-06-16 20:04       ` Emil Velikov [this message]
2016-06-14 18:50 ` [PATCH 04/14] drm: Move master functions into drm_auth.c Daniel Vetter
2016-06-15 11:31   ` Chris Wilson
2016-06-15 15:47     ` Daniel Vetter
2016-06-14 18:51 ` [PATCH 05/14] drm: Extract drm_master_open Daniel Vetter
2016-06-15 11:41   ` [Intel-gfx] " Chris Wilson
2016-06-14 18:51 ` [PATCH 06/14] drm: Extract drm_master_relase Daniel Vetter
2016-06-15 11:43   ` [Intel-gfx] " Chris Wilson
2016-06-16  8:18     ` Daniel Vetter
2016-06-14 18:51 ` [PATCH 07/14] drm: Only do the hw.lock cleanup in master_relase for !MODESET Daniel Vetter
2016-06-15 11:48   ` Chris Wilson
2016-06-15 15:49     ` [Intel-gfx] " Daniel Vetter
2016-06-14 18:51 ` [PATCH 08/14] drm: Move authmagic cleanup into drm_master_release Daniel Vetter
2016-06-15 11:51   ` Chris Wilson
2016-06-14 18:51 ` [PATCH 09/14] drm: Protect authmagic with master_mutex Daniel Vetter
2016-06-15 11:54   ` [Intel-gfx] " Chris Wilson
2016-06-15 15:52     ` Daniel Vetter
2016-06-14 18:51 ` [PATCH 10/14] drm: Mark authmagic ioctls as unlocked Daniel Vetter
2016-06-15 11:55   ` [Intel-gfx] " Chris Wilson
2016-06-14 18:51 ` [PATCH 11/14] drm: Mark set/drop master ioctl " Daniel Vetter
2016-06-15 11:56   ` [Intel-gfx] " Chris Wilson
2016-06-14 18:51 ` [PATCH 12/14] drm: Move master pointer from drm_minor to drm_device Daniel Vetter
2016-06-15 12:10   ` [Intel-gfx] " Chris Wilson
2016-06-15 16:01     ` Daniel Vetter
2016-06-15 16:33       ` Chris Wilson
2016-06-15 19:54         ` [Intel-gfx] " Daniel Vetter
2016-06-14 18:51 ` [PATCH 13/14] drm: Clean up drm_crtc.h Daniel Vetter
2016-06-14 18:51 ` [PATCH 14/14] drm: Use dev->name as fallback for dev->unique Daniel Vetter
2016-06-15  5:42 ` ✓ Ro.CI.BAT: success for Cruft removal around drm_master Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACvgo51iHDwz2qrHx2RZoEUHXBZyzYyYjdvKW1dBPiZFYjNmOQ@mail.gmail.com \
    --to=emil.l.velikov@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.