On 1/28/26 4:09 PM, Danilo Krummrich wrote:
On Wed Jan 28, 2026 at 4:27 PM CET, Joel Fernandes wrote:
I will go over these concerns, just to clarify - do you mean forbidding
*any* lock or do you mean only forbidding non-atomic locks? I believe we
can avoid non-atomic locks completely - actually I just wrote a patch
before I read this email to do just. If we are to forbid any locking at
all, that might require some careful redesign to handle the above race
afaics.
It's not about the locks themselves, sleeping locks are fine too. It's about
holding locks that are held elsewhere when doing memory allocations that can
call back into MMU notifiers or the shrinker.
If you look at core kernel mm, you'll find a similar constraint: avoid
holding any locks while allocating--unless you are in the reclaim code
itself.
Especially when dealing with page tables.
So this is looking familiar to me and I agree with the constraint, fwiw.
I.e. if in the fence signalling critical path you wait for a mutex that is held
elsewhere while allocating memory and the memory allocation calls back into the
shrinker, you may end up waiting for your own DMA fence to be signaled, which
causes a deadlock.
Right, and the list of pitfalls such as this is basically limited only
by your imagination--it's long. :)
thanks,
--
John Hubbard
