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.
