Messages in this thread |  | | Date | Fri, 21 Sep 2001 13:18:41 -0400 | From | Benjamin LaHaise <> | Subject | Re: 2.4.10pre13aa1 |
| |
On Fri, Sep 21, 2001 at 09:57:21AM +0200, Andrea Arcangeli wrote: > Only in 2.4.10pre13aa1: 00_unmap-dirty-pte-1 > > I grepped over the whole 600 pages of the latest x86 system developer > manual and I couldn't find the proof that I'm wrong. > > We can have pagecache pages with pte writeable and non dirty at some > point. > > Now what happens if the userspace task in the other cpu touches the > writeable page between our "ptep_get_and_clear" and the > "flush_tlb_page"? Is the resulting pte still zero and the task get into > a page fault? Or as I am worried it could also just end with the pte > with only the dirty bit set? Does somebody know for sure? I can > imagine the cpu finding the tlb state writeable, and issuing just a > locked bit test and set in the pte without caring to check if the pte > is zero or not. > > If the cpu just set the bit this patch will avoid to lose a shared > mapping update. Otherwise it's a safe noop so I keep it applied > until this issue is sorted out.
I've tested this on all the machines I could get my hands on, and every single CPU will take a page fault if the pte is not present on dirtying the page. If people are truely paranoid, then make it a boot time assertion.
-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/
|  |