linux-mips
[Top] [All Lists]

Re: [PATCH] fix cache coherency issues

To: ralf@linux-mips.org
Subject: Re: [PATCH] fix cache coherency issues
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Thu, 24 Aug 2006 20:38:38 +0900 (JST)
Cc: nigel@mips.com, linux-mips@linux-mips.org
In-reply-to: <20060824111515.GA4490@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <44EC87C9.8010402@mips.com> <20060824.101531.07643963.nemoto@toshiba-tops.co.jp> <20060824111515.GA4490@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
On Thu, 24 Aug 2006 12:15:15 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> Your patch also still contains copy_user_page().  The only user of it used
> to be copy_user_highpage() so after our rewrite it can go away.  I've
> already applied both fixes to my working version of the patch.

Yes, it is intentional.  I keep copy_user_page() just because it is
described in cachetlb.txt and exported.

Of course we can remove it.  I do not care :-) Also I wondered we
should export copy_user_highpage() or not ...

> Your patch only maps the source page.  I'm trying to map the destination
> page also and I'm hitting a few issues with it.

If you wanted to map the destination, you must writeback the dcache
via kernel mapping first.  The dcache can contain dirty data for the
page by previous usage.  And if the page was executable, we must flush
the destination page after copy_page() (via coherent mapping) anyway
for I/D coherency.

So now I think mapping the destination is not worth to do.

---
Atsushi Nemoto

<Prev in Thread] Current Thread [Next in Thread>