On Wed, 20 Dec 2006, Peter Zijlstra wrote: > > fix page_mkclean_one()
Congratulations on getting to the bottom of it, Peter (if you have: I haven't digested enough of the thread to tell). I'm mostly offline at present, no time for dialogue, I'll throw out a few remarks and run... > > it had several issues: > - it failed to flush the cache It's unclear to me why it should need to flush the cache, but I don't know much about that, and mprotect does flush the cache in advance - I think others will tell you that if it does need to be flushed, it must be flushed while there's still a valid pte (on some arches at least). > - it failed to flush the tlb Eh? It flushed the TLB inside ptep_establish, didn't it? I guess you mean you've found a race before it flushed the TLB. > - it failed to do s390 (s390 guys, please verify this is now correct) Hmm, I thought we cleared it with them back at the time. > > Also, clear in a loop to ensure SMP safeness as suggested by Arjan. Yikes. Well, please compare with mprotect's change_pte_range. I think I took that as the relevant standard when checking your implementation, and back then satisfied myself that what you were doing was equivalent. If page_mkclean_one is now agreed to be significantly defective, then I suspect change_pte_range is also; perhaps others too. (But I haven't found time to do more than skim through the thread, I've not thought through the issues at all: I am surprised that it's now found defective, we looked at it long and hard back then.) And trivial point: please undo those distracting "pte" to "ptep" mods: if you want to call pte pointers ptep, throughout rmap.c and throughout mm, that's another patch entirely (which I won't welcome, but others may). Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
