Re: not issuing vma_start_write() in dup_mmap() if the caller is single-threaded

["Liam R. Howlett" <Liam.Howlett@oracle.com>]

* Mateusz Guzik <mjguzik@gmail.com> [250330 15:43]:
> On Sun, Mar 30, 2025 at 9:23 PM Suren Baghdasaryan <surenb@google.com> wrote:
> > > However, the good news is that mm_count tends to be 1. If both
> > > mm_count and mm_users are 1, then there is no usefaultfd in use and
> > > nobody to add it either.
> >
> > I'm not sure... IIUC new_userfaultfd() does not take mmap_lock while
> > calling mmgrab(), therefore I think it can race with the code checking
> > its value.
> >

Considering the mm struct isn't the only way to find the vmas and there
are users who use other locks to ensure the mm and vma don't go away
(rmap, for example).  It is reasonable to think that other users may use
the vma lock to avoid mm_struct accesses racing.

Although I don't know of a way this is unsafe today, we are complicating
the locking story of the mm with this change and no data has been given
on the benefit.  I don't recall any regression caused by the addition of
per-vma locking?

> 
> It issues:
> ctx->mm = current->mm;
> ...
> mmgrab(ctx->mm);
> 
> Thus I claim if mm_count is 1 *and* mm_users is 1 *and* we are in
> dup_mmap(), nobody has a userfaultfd for our mm and there is nobody to
> create it either and the optimization is saved.

mm_count is lazy, so I am not entirely sure we can trust what it says.
But maybe that's only true of mmgrab_lazy_tlb() now?

Thanks,
Liam