Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763630AbZAPF6r (ORCPT ); Fri, 16 Jan 2009 00:58:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753304AbZAPF5s (ORCPT ); Fri, 16 Jan 2009 00:57:48 -0500 Received: from palinux.external.hp.com ([192.25.206.14]:38863 "EHLO mail.parisc-linux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752852AbZAPF5r (ORCPT ); Fri, 16 Jan 2009 00:57:47 -0500 Date: Thu, 15 Jan 2009 22:57:30 -0700 From: Matthew Wilcox To: MinChan Kim Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, npiggin@suse.de, akpm@linux-foundation.org Subject: Re: [PATCH] Remove needless flush_dcache_page call Message-ID: <20090116055729.GF31013@parisc-linux.org> References: <20090116052804.GA18737@barrios-desktop> <20090116053338.GC31013@parisc-linux.org> <20090116055119.GA6515@barrios-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090116055119.GA6515@barrios-desktop> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2195 Lines: 46 On Fri, Jan 16, 2009 at 02:51:19PM +0900, MinChan Kim wrote: > On Thu, Jan 15, 2009 at 10:33:38PM -0700, Matthew Wilcox wrote: > > 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). 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." -- 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/