[PATCH] drm/amdgpu: add flag for high priority contexts

[Christian König]

Am 04.01.2017 um 21:56 schrieb Andres Rodriguez:
> Hey Serguei
>
>
> On 2017-01-04 07:56 AM, Christian König wrote:
>> Am 04.01.2017 um 12:03 schrieb Sagalovitch, Serguei:
>>> Andres,
>>>
>>> I have on rather generic design question:
>>>
>>> Why we want to restrict it to CAP_SYS_ADMIN?
>>>
>>> +       if (priority == AMD_SCHED_PRIORITY_HIGH && 
>>> !capable(CAP_SYS_ADMIN))
>>> +               return -EACCES;
>>>
>>> Should we make it generic? My understanding is that If we follow 
>>> "nice" semantic
>>> then it will not require such privilege.
>>
>> Well it follows the "nice" semantic, the the documentation of the 
>> nice system call:
>>
>>        nice()  adds inc to the nice value for the calling process. (A 
>> higher nice value means a low priority.)  Only the superuser may 
>> specify a negative increment, or priority increase.  The range
>>        for nice values is described in getpriority(2).
>>
>> Of course the nice limit is more fine grained these days. IIRC it was 
>> a soft resource limit now the last time I looked.
>>
>> We would essentially need something similar for the GPU if we want to 
>> allow a regular process to get a higher priority.
>
> As Christian mentioned this is based on the same restrictions as nice.
>
> Also thinking along the lines of, it would be easier in the future to 
> relax requirements than to increase them.

That is a rather interesting idea. Instead of increasing the priority 
for the compositor we could decrease it for everybody else. We could do 
this by setting an environment variable for the loged in user for example.

This would be similar to how nice() handles it and could avoid some of 
the security problems.

>
> If we end up in a scenario where we want looser restrictions, that can 
> be implemented as a new feature.
>
> However, the opposite is not true. If we require to tighten 
> restrictions that would result in an backwards compatibility breakage, 
> and the patch would not be allowed. Apps that used to have access no 
> longer have access.

Yes exactly. As soon as an interface gets upstream it is nailed in stone.

This means that we can't break existing userspace by adding more 
restrictions, but we can easily lower restrictions.

Regards,
Christian.

>
> Regards,
> Andres
>
>>
>> Regards,
>> Christian.
>>
>>>
>>> Sincerely yours,
>>> Serguei Sagalovitch
>>>
>>>      _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>