[PATCH 2/3] drm: introduce DRIVER_FORCE_AUTH

Koenig, Christian Christian.Koenig at amd.com
Wed Jul 17 08:26:11 UTC 2019


Hi Emil,

Sorry for the delay, finally coming back to this after my vacation.

Am 03.07.19 um 17:14 schrieb Emil Velikov:
> 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, but this would once more mean that we expose the same 
functionality on the primary node we do on the render node.

And that is exactly what I want to prevent, because I think it is a very 
bad idea and will result in basically deprecating the render node.

For the problem at hand it was sufficient to drop the DRM_AUTH flag from 
the driver IOCTLs and I don't see a reason why we should go further than 
this.

Please just completely drop this whole approach,
Christian.

>
> -Emil



More information about the amd-gfx mailing list