Messages in this thread | | | Date | Wed, 20 Dec 2006 13:00:53 +0000 (GMT) | From | Hugh Dickins <> | Subject | Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3) |
| |
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 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/
| |