[PATCH 2/3] drm: introduce DRIVER_FORCE_AUTH

[Koenig, Christian]

Am 03.07.2019 17:14 schrieb Emil Velikov <emil.l.velikov at gmail.com>:
On Wed, 3 Jul 2019 at 15:58, Koenig, Christian <Christian.Koenig at amd.com> wrote:
> Am 03.07.2019 16:51 schrieb Emil Velikov <emil.l.velikov at gmail.com>:
>
> On Wed, 3 Jul 2019 at 15:33, Koenig, Christian <Christian.Koenig at amd.com> wrote:
> > Am 03.07.2019 16:00 schrieb Emil Velikov <emil.l.velikov at gmail.com>:
> >
> > On Wed, 3 Jul 2019 at 14:48, Koenig, Christian <Christian.Koenig at amd.com> wrote:
> > >
> > > Well this is still a NAK.
> > >
> > > As stated previously please just don't remove DRM_AUTH and keep the functionality as it is.
> > >
> > AFAICT nobody was in favour of your suggestion to remove DRM_AUTH from
> > the handle to/from fd ioclts.
> > Thus this seems like the second best option.
> >
> >
> > Well just keep it. As I said please don't change anything here.
> >
> > Dropping DRM_AUTH from the driver IOCTLs was sufficient to work around the problems at hand far as I know.
> >
> We also need the DRM_AUTH for handle to/from fd ones. Mesa drivers use
> those ioctls.
>
>
> Yeah, but only for importing/exporting things.
>
> And in those cases we either already gave render nodes or correctly authenticated primary nodes.
>
> So no need to change anything here as far as I see.
>
Not quite. When working with the primary node we have the following scenarios:
 - handle to fd -> pass fd to other APIs - gbm, opencl, vdpau, etc
 - handle to fd -> fd to handle - use it internally

Yeah, I'm aware of that but hoped that this would be a rather rare case.

I need to take another closer look on this, but currently I am on vacation and won't have time next week either.

Trying to get back to this as soon as possible,
Christian.


-Emil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20190706/6fa99509/attachment.html>