On Fri, Feb 07, 2020 at 09:52:34AM +0100, Peter Zijlstra wrote: > On Thu, Feb 06, 2020 at 01:20:24PM -0800, Matthew Wilcox wrote: > > If you use SRCU, why would you need a second page table walk? > > Because SRCU only ensures the VMA object remains extant, it does not > prevent modification of it, normally that guarantee is provided by > mmap_sem, but we're not going to use that. > > Instead, what we serialize on is the (split) ptlock. So we do the first > page-walk and ptlock to verify the vma-lookup, then we drop ptlock and > do the file-io, then we page-walk and take ptlock again, verify the vma > (again) and install the PTE. If anything goes wrong, we bail. > > See this patch: > > https://lkml.kernel.org/r/301fb863785f37c319b493bd0d43167353871804.1479465699.git.ldufour@xxxxxxxxxxxxxxxxxx OK, this gets to a difference in how we see modification to a VMA working. You take a seqcount in patch 5: https://lore.kernel.org/linux-mm/95790e53bfcfb536eb8f1dcdf4750e7e8050d8f4.1479465699.git.ldufour@xxxxxxxxxxxxxxxxxx/ I was intending to postpone the page table flushing parts of a VMA modification until a grace period had passed, but what you're doing is faster.
