Re: [PATCH v12 5/6] khugepaged: enable collapse pmd for pte-mapped THP

[Oleg Nesterov]

On 08/12, Kirill A. Shutemov wrote:
>
> On Mon, Aug 12, 2019 at 03:22:58PM +0200, Oleg Nesterov wrote:
> > On 08/12, Kirill A. Shutemov wrote:
> > >
> > > On Fri, Aug 09, 2019 at 06:01:18PM +0000, Song Liu wrote:
> > > > +		if (pte_none(*pte) || !pte_present(*pte))
> > > > +			continue;
> > >
> > > You don't need to check both. Present is never none.
> >
> > Agreed.
> >
> > Kirill, while you are here, shouldn't retract_page_tables() check
> > vma->anon_vma (and probably do mm_find_pmd) under vm_mm->mmap_sem?
> >
> > Can't it race with, say, do_cow_fault?
>
> vma->anon_vma can race, but it doesn't matter. False-negative is fine.
> It's attempt to avoid taking mmap_sem where it can be not productive.

I guess I misunderstood the purpose of this check or your answer...

Let me reword my question. Why can retract_page_tables() safely do
pmdp_collapse_flush(vma) without additional checks similar to what
collapse_pte_mapped_thp() does?

I thought that retract_page_tables() checks vma->anon_vma to ensure that
this vma doesn't have a cow'ed PageAnon() page. And I still can't understand
why can't it race with __handle_mm_fault() paths.

Suppose that shmem_file was mmaped with PROT_READ|WRITE, MAP_PRIVATE.
To simplify, suppose that a non-THP page was already faulted in,
pte_present() == T.

Userspace writes to this page.

Why __handle_mm_fault()->handle_pte_fault()->do_wp_page()->wp_page_copy()
can not cow this page and update pte after the vma->anon_vma chech and
before down_write_trylock(mmap_sem) ?

Oleg.