On Sat, Apr 13, 2024 at 02:46:56PM -0700, Suren Baghdasaryan wrote: > On Fri, Apr 12, 2024 at 8:31 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > - Rename lock_vma() to uffd_lock_vma() because it really is uffd > > specific. > > I'm planning to expand the scope of lock_vma() and reuse it for > /proc/pid/maps reading under per-VMA locks. No objection to renaming > it for now but I'll likely rename it back later once it's used in more > places. That would seem like a mistake. The uffd lock_vma() will create an anon_vma for VMAs that don't have one, and you wouldn't want that. It seems to me that lock_vma_under_rcu() does everything you want except the fallback to mmap_read_lock(). And I'm not sure there's a good way to package that up ... indeed, I don't see why you'd want the "take the mmap_lock, look up the VMA, drop the mmap read lock" part at all -- once you've got the mmap_lock, just hold it until you're done.
