On Sat, Dec 19, 2020 at 6:49 PM Andrea Arcangeli aarcange@redhat.com 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.