Messages in this thread | | | Subject | Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE | From | Benjamin Herrenschmidt <> | Date | Mon, 24 May 2004 14:44:00 +1000 |
| |
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/
| |