Messages in this thread | | | Date | Tue, 13 Aug 2019 15:30:34 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH v12 5/6] khugepaged: enable collapse pmd for pte-mapped THP |
| |
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.
| |