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
