Re: [PATCH V2] mm: Recheck page table entry with page table lock held

[Kirill A. Shutemov]

On Fri, Oct 25, 2019 at 11:13:58AM +0800, Figo.zhang wrote:
> Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxx> ä2018å9æ26æåä äå11:19åéï
> 
> > We clear the pte temporarily during read/modify/write update of the pte.
> > If we
> > take a page fault while the pte is cleared, the application can get
> > SIGBUS. One
> > such case is with remap_pfn_range without a backing vm_ops->fault callback.
> > do_fault will return SIGBUS in that case.
> >
> what is " remap_pfn_range without a backing vm_ops->fault callback ", would
> you like  elaborate the scenario?
>  is it the case using remap_pfn_range()  in drivers mmap() file operations?
> if in that case, why it will trap into do_fault?

Because there's no page mapped there during the race.

> >
> > cpu 0                                           cpu1
> > mprotect()
> > ptep_modify_prot_start()/pte cleared.
> > .
> > .                                               page fault.
> > .
> > .
> > prep_modify_prot_commit()
> 
> 
>   i am confusing this  scenario, when CPU0 will call
> in change_pte_range()->ptep_modify_prot_start() to clear the pte content,
> and
> on the other thread, in handle_pte_fault(), pte_offset_map() can get the
> pte, and the pte is not invalid, it's pte is valid but just the content is
> all zero, so why it will call into do_fault?
> 
> in  handle_pte_fault():
>     vmf->pte = pte_offset_map(vmf->pmd, vmf->address);
>     if (!vmf->pte) {
>             return do_fault(vmf);
>     }

This case handles the situation when pte is none (clear) or page table is
not allocated at all.

-- 
 Kirill A. Shutemov