[PATCH 2/2] drm/amdgpu: add AMDGPURESET uevent on AMD GPU reset

[Christian König]

Hi Amarnath,

not a bad idea, but that won't work either because you really need to 
return to make sure that a potential next reset can run.

What could be done is to have a work item which does that, but then I 
think it would just be easier to teach the udev function a GFP mask.

Regards,
Christian.


Am 17.01.22 um 15:19 schrieb Somalapuram, Amaranath:
> Hi Christian,
>
> if sending udev event during reset is going to create problem, we can 
> move this code from reset sequence to re-int  (after GPU reset 
> succeeded).
>
> Regards,
>
> S.Amarnath
>
> On 1/17/2022 5:27 PM, Christian König wrote:
>> Am 17.01.22 um 12:43 schrieb Sharma, Shashank:
>>> Hello Christian,
>>>
>>> On 1/17/2022 11:37 AM, Christian König wrote:
>>>> Am 17.01.22 um 11:34 schrieb Somalapuram, Amaranath:
>>>>> [SNIP]
>>>>> Any suggestion how we can notify user space during this situation. 
>>>>
>>>> Well trace points should work. They use a ring buffer and are 
>>>> specially made to work in such situations.
>>>
>>> We are anyways sending a trace event with data, but can trace event 
>>> be a wake up source for an application (like a tracer) ? This DRM 
>>> event is just to indicate that reset happened, so app has to read 
>>> from trace file.
>>
>> Yeah, that's a really good question I can't fully answer. As far as I 
>> know you can filter in userspace what you get from the tracer, but I 
>> don't know if you can block on a specific event.
>>
>> Christian.
>>
>>>
>>>>
>>>> Alternative would be to audit the udev code and allow giving a GFP 
>>>> mask to the function to make sure that we don't run into the deadlock.
>>>>
>>>> Another alternative is a debugfs file which just blocks for the 
>>>> next reset to happen.
>>>>
>>>
>>> - Shashank
>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>> Regards,
>>>>>
>>>>> S.Amarnath
>>>>>
>>>>
>>