Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file contentcorruption on ext3)

[Linus Torvalds]

On Fri, 22 Dec 2006, Peter Zijlstra wrote:
> 
> fix page_mkclean_one()
> 
>  - add flush_cache_page() for all those virtual indexed cache
>    architectures.

I think the flush_cache_page() should be after we've actually flushed it 
from the TLB and re-inserted it (this is one reason why I did the 
"ptep_exchange()" version of this). Otherwise somebody can still write to 
the page _after_ the cache flush..

>  - handle s390.

Yeah, that looks like the proper way to handle that.

That said, it looks like we still see corruption. You may not, but Martin 
and Andrei still report problems, even with all the patches (including the 
last one from Andrew that avoids "dirty" going negative under some 
circumstances, and explains the "slow and/or never completed" case that 
Gordon and Martin saw).

The good news is that I think the code now is cleaner and more 
understandable. The bad news is that nothing we've ever tried seems to 
have fixed the _problem_.

And I don't think it's page_mkclean(). Especially not since the ARM people 
are seeing this under UP without PREEMPT. In that kind of schenario, the 
only possible races tend to be from things that actually block: 
"set_page_dirty()" (which blocks on IO in balancing), memory allocations, 
and obviously doing actual IO.

And it's not a virtual cache problem, since others see it on x86.

Of course, since it's quite possibly two different issues, maybe the 
virtual cache flush is required in order to force write-back to memory 
(which in turn is required for the DMA for the actual write!). So the ARM 
issue certainly could be due to the flush_cache_page() thing...

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