On Fri, Jun 09, 2023 at 03:30:10PM -0700, Suren Baghdasaryan wrote: > On Fri, Jun 9, 2023 at 1:42 PM Peter Xu <peterx@xxxxxxxxxx> wrote: > > > > On Thu, Jun 08, 2023 at 05:51:56PM -0700, Suren Baghdasaryan wrote: > > > migration_entry_wait does not need VMA lock, therefore it can be dropped > > > before waiting. Introduce VM_FAULT_VMA_UNLOCKED to indicate that VMA > > > lock was dropped while in handle_mm_fault(). > > > Note that once VMA lock is dropped, the VMA reference can't be used as > > > there are no guarantees it was not freed. > > > > Then vma lock behaves differently from mmap read lock, am I right? Can we > > still make them match on behaviors, or there's reason not to do so? > > I think we could match their behavior by also dropping mmap_lock here > when fault is handled under mmap_lock (!(fault->flags & > FAULT_FLAG_VMA_LOCK)). > I missed the fact that VM_FAULT_COMPLETED can be used to skip dropping > mmap_lock in do_page_fault(), so indeed, I might be able to use > VM_FAULT_COMPLETED to skip vma_end_read(vma) for per-vma locks as well > instead of introducing FAULT_FLAG_VMA_LOCK. I think that was your idea > of reusing existing flags? Yes. I'd suggest we move this patch out of the series as it's not really part of it on enabling swap + uffd. It can be a separate patch and hopefully it'll always change both vma+mmap lock cases, and with proper reasonings. Thanks, -- Peter Xu
