Re: [PATCH] Remove needless flush_dcache_page call

On Thu, Jan 15, 2009 at 10:57:30PM -0700, Matthew Wilcox wrote:

On Fri, Jan 16, 2009 at 02:51:19PM +0900, MinChan Kim wrote:

quoted

On Thu, Jan 15, 2009 at 10:33:38PM -0700, Matthew Wilcox wrote:

quoted

Sorry, no.  You have to call fluch_dcache_page() in two situations --
when the kernel is going to read some data that userspace wrote, *and*
when userspace is going to read some data that the kernel wrote.  From a
quick look at the patch, this seems to be the second case.  The kernel
wrote data to a pagecache page, and userspace should be able to read it.

To understand why this is necessary, consider a processor which is
virtually indexed and has a writeback cache.  The kernel writes to a
page, then a user process reads from the same page through a different
address.  The cache doesn't find the data the kernel wrote because it
has a different virtual index, so userspace reads stale data.

I see. :)

Thanks for quick reponse and good explaination.
Hmm,.. one more question. 

I can't find flush_dcache_page call in mpage_readpage which is 
generic read function. In case of ext fs, it use mpage_readpage 
with readpage.

who and where call flush_dcache_page in mpage_readpage call path?

Most I/O devices will do DMA to the page in question and thus the kernel
hasn't written to it and the CPU won't have the data in cache.  For the
few devices which can't do DMA, it's the responsibility of the device
driver to call flush_dcache_page() (or some other flushing primitive).

Hmm.. Now I am confusing. 
If devicer driver or with DMA makes sure cache consistency,
Why filesystem code have to handle it ?

See the gdth driver for an example:

            address = kmap_atomic(sg_page(sl), KM_BIO_SRC_IRQ) + sl->offset;
            memcpy(address, buffer, cpnow);
            flush_dcache_page(sg_page(sl));
            kunmap_atomic(address, KM_BIO_SRC_IRQ);

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

--
Kinds regards,
MinChan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>