lkml.org 
[lkml]   [2019]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V2] mm: Recheck page table entry with page table lock held
On Fri, Oct 25, 2019 at 11:13:58AM +0800, Figo.zhang wrote:
> Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> 于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

\
 
 \ /
  Last update: 2019-10-28 13:08    [W:0.063 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site