On Mon, Jun 12, 2023 at 6:28 AM Peter Xu <peterx@xxxxxxxxxx> wrote: > > 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. Ok, I can move it out with mmap_lock support only and then add per-vma lock support in my patchset (because this path is still part of do_swap_page and my patchset enables swap support for per-vma locks). > > Thanks, > > -- > Peter Xu >
