lkml.org 
[lkml]   [2004]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] ppc64: Fix possible race with set_pte on a present PTE
From
Date
On Mon, 2004-05-24 at 14:36, Linus Torvalds wrote:
> On Mon, 24 May 2004, Benjamin Herrenschmidt wrote:
> >
> > Typically, you can have a thread faulting on a page. It goes through hash_page,
> > doesn't find the entry, and gets to do_page_fault(). However, just before it
> > takes the mm sem, another thread actually mmap's that page in. Thus we end up
> > in handle_pte_fault() with a present PTE which has a valid mapping already.
>
> Ok, with you so far. But I don't see how you get to set_pte() that way,
> since handle_pte_fault() will re-test the pte_present() bit, and never
> even try to set_pte() if one already exists. Hmm?

No, it doesn't. It tests it, if !present, it goes to do_no_page,
do_file_page or do_swap_page, but the,i if present, it does:

entry = pte_mkyoung(entry);
ptep_establish(vma, address, pte, entry);
update_mmu_cache(vma, address, entry);
pte_unmap(pte);
spin_unlock(&mm->page_table_lock);
return VM_FAULT_MINOR;

Which is, I think, the software PAGE_ACCESSED path used on some archs.

(ptep_establish does set_pte)

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.203 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site