On Sat, Dec 19, 2020 at 6:49 PM Andrea Arcangeli <aarcange@xxxxxxxxxx> wrote: > > On Sat, Dec 19, 2020 at 06:01:39PM -0800, Andy Lutomirski wrote: > > I missed the beginning of this thread, but it looks to me like > > userfaultfd changes PTEs with not locking except mmap_read_lock(). It > > There's no mmap_read_lock, I assume you mean mmap_lock for reading. Yes. > > The ptes are changed always with the PT lock, in fact there's no > problem with the PTE updates. The only difference with mprotect > runtime is that the mmap_lock is taken for reading. And the effect > contested for this change doesn't affect the PTE, but supposedly the > tlb flushing deferral. Can you point me at where the lock ends up being taken in this path? I apparently missed it somewhere. > Anyway to wait the wrprotect to do the deferred flush, before the > unprotect can even start, one more mutex in the mm to take in all > callers of change_protection_range with the mmap_lock for reading may > be enough. I'll read the code again tomorrow.
