Lockdep spalt on killing a processes

[Andrey Grodzovsky]

On 2021-10-27 10:50 a.m., Christian König wrote:
> Am 27.10.21 um 16:47 schrieb Andrey Grodzovsky:
>>
>> On 2021-10-27 10:34 a.m., Christian König wrote:
>>> Am 27.10.21 um 16:27 schrieb Andrey Grodzovsky:
>>>> [SNIP]
>>>>>
>>>>>> Let me please know if I am still missing some point of yours.
>>>>>
>>>>> Well, I mean we need to be able to handle this for all drivers.
>>>>
>>>>
>>>> For sure, but as i said above in my opinion we need to change only 
>>>> for those drivers that don't use the _locked version.
>>>
>>> And that absolutely won't work.
>>>
>>> See the dma_fence is a contract between drivers, so you need the 
>>> same calling convention between all drivers.
>>>
>>> Either we always call the callback with the lock held or we always 
>>> call it without the lock, but sometimes like that and sometimes 
>>> otherwise won't work.
>>>
>>> Christian.
>>
>>
>> I am not sure I fully understand what problems this will cause but 
>> anyway, then we are back to irq_work. We cannot embed irq_work as 
>> union within dma_fenc's cb_list
>> because it's already reused as timestamp and as rcu head after the 
>> fence is signaled. So I will do it within drm_scheduler with single 
>> irq_work per drm_sched_entity
>> as we discussed before.
>
> That won't work either. We free up the entity after the cleanup 
> function. That's the reason we use the callback on the job in the 
> first place.


Yep, missed it.


>
> We could overlead the cb structure in the job though.


I guess, since no one else is using this member it after the cb executed.

Andrey


>
> Christian.
>
>>
>> Andrey
>>
>>
>>>
>>>>
>>>> Andrey
>>>
>