[PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

[Koenig, Christian]

Am 21.06.19 um 12:53 schrieb Emil Velikov:
> On 2019/06/21, Koenig, Christian wrote:
>> [SNIP]
>> Well partially. That RADV broke is unfortunate, but we have done so many
>> customized userspace stuff both based on Mesa/DDX as well as closed
>> source components that it is just highly likely that we would break
>> something else as well.
>>
> As an engineer I like to work with tangibles. The highly likely part is
> probable, but as mentioned multiple times the series allows for a _dead_
> trivial way to address any such problems.

Well to clarify my concern is that this won't be so trivial.

You implemented on workaround for one specific case and it is perfectly 
possible that for other cases we would have to completely revert the 
removal of DRM_AUTH.

>>> In particular, that user-space will "remove" render nodes.
>> Yes, that is my main concern here. You basically make render nodes
>> superfluously. That gives userspace all legitimization to also remove
>> support for them. That is not stupid or evil or whatever, userspace
>> would just follow the kernel design.
>>
> Do you have an example of userspace doing such an extremely silly thing?
> It does seem like suspect you're a couple of steps beyond overcautious,
> perhaps rightfully so. Maybe you've seen some closed-source user-space
> going crazy? Or any other projects?

The key point is that I don't think this is silly or strange or crazy at 
all. See the kernel defines the interface userspace can and should use.

When the kernel defines that everything will work with the primary node 
it is perfectly valid for userspace to drop support for the render node.

I mean why should they keep this? Just because we tell them not to do this?

> In other words, being cautious is great, but without references of
> misuse it's very hard for others to draw the full picture.
>
>>> I'm really sad that amdgpu insists on standing out, hope one day it will
>>> converge. Yet since all other maintainers are ok with the series, I'll
>>> start merging patches in a few hours. I'm really sad that amdgpu wants
>>> to stand out, hope it will converge sooner rather than later.
>>>
>>> Christian, how would you like amdgpu handled - with a separate flag in
>>> the driver or shall we special case amdgpu within core drm?
>> No, I ask you to please stick around DRM_AUTH for at least amdgpu and
>> radeon. And NOT enable any render node functionality for them on the
>> primary node.
>>
> My question is how do you want this handled:
>   - DRM_PLEASE_FORCE_AUTH - added to AMDGPU/RADEON, or
>   - driver_name == amdgpu, in core DRM.

I want to keep DRM_AUTH in amdgpu and radeon for at least the next 5-10 
years.

At least until we have established that nobody is using the primary node 
for command submission any more. Plus some grace time to make sure that 
this has been spread enough.

Regards,
Christian.

>
>
> Thanks
> Emil