Date: Sun, 25 May 2003 22:36:55 -0700 (PDT)
Message-Id: <20030525.223655.123997551.davem@redhat.com>
To: mika.penttila@kolumbus.fi
Cc: rmk@arm.linux.org.uk, akpm@digeo.com, hugh@veritas.com,
       LW@KARO-electronics.de, linux-kernel@vger.kernel.org
Subject: Re: [patch] cache flush bug in mm/filemap.c (all kernels >=
 2.5.30(at least))
From: "David S. Miller" <davem@redhat.com>
In-Reply-To: <3ED1A7E2.6080607@kolumbus.fi>
References: <3ED1A0FE.3000101@kolumbus.fi>
	<20030525.220852.42800415.davem@redhat.com>
	<3ED1A7E2.6080607@kolumbus.fi>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 928
Lines: 20

   From: Mika Penttil? <mika.penttila@kolumbus.fi>
   Date: Mon, 26 May 2003 08:36:34 +0300

   ah, ok. so there are cache issues even if if the user pte is not 
   established yet? Then it seems natural to couple flush_dcache_page
   with pte establishing, not at the driver level.

flush_dcache_page() or some architecture level equivalent belongs
whereever the kernel uses CPU store instructions to modify a page's
contents.

When IDE uses PIO to do a data transfer, the flush belongs there.
Right now this is occuring in the architecture defined IDE insw/outsw
macros.  It very well might be more efficient to do this at a higher
level where the total extent of the I/O is known.
-
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/