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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/13, Oleg Nesterov wrote:
>
> 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) ?

OK, probably this is impossible, collapse_shmem() does unmap_mapping_pages(),
so handle_pte_fault() will call shmem_fault() which iiuc should block in
find_lock_entry() because new_page is locked, and thus down_write_trylock()
can't succeed.

Nevermind, I am sure I missed something. Perhaps you can update the comments
to make this more clear.

Oleg.





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux