Re: Lockdep spalt on killing a processes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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





[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux