On 1/29/26 5:59 PM, Joel Fernandes wrote: > On 1/29/26 8:12 PM, John Hubbard wrote: >> On 1/29/26 4:26 PM, Joel Fernandes wrote: >>> Based on the below discussion and research, I came up with some deadlock >>> scenarios that we need to handle in the v6 series of these patches. >>> [...] >>> memory allocations under locks that we need in the dma-fence signaling >>> critical path (when doing the virtual memory map/unmap) >> >> unmap? Are you seeing any allocations happening during unmap? I don't >> immediately see any, but that sounds surprising. > > Not allocations but we are acquiring locks during unmap. My understanding > is (at least some) unmaps have to also be done in the dma fence signaling > critical path (the run stage), but Danilo/you can correct me if I am wrong > on that. We cannot avoid all locking but those same locks cannot be held in > any other paths which do a memory allocation (as mentioned in one of the > deadlock scenarios), that is probably the main thing to check for unmap. >
Right, OK we are on the same page now: no allocations happening on unmap, but it can still deadlock, because the driver is typically going to use a single lock to protect calls both map and unmap-related calls to the buddy allocator. For the deadlock above, I think a good way to break that deadlock is to not allow taking that lock in a fence signaling calling path. So during an unmap, instead of "lock, unmap/free, unlock" it should move the item to a deferred-free list, which is processed separately. Of course, this is a little complex, because the allocation and reclaim has to be aware of such lists if they get large. thanks, -- John Hubbard
