linux-mips
[Top] [All Lists]

Re: missing flush_dcache_page call in 2.4 kernel

To: anemo@mba.ocn.ne.jp
Subject: Re: missing flush_dcache_page call in 2.4 kernel
From: Peter Horton <phorton@bitbox.co.uk>
Date: Thu, 25 Mar 2004 14:50:09 +0000
Cc: linux-mips@linux-mips.org
In-reply-to: <20040325143319.GA873@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20040325.224229.112629304.nemoto@toshiba-tops.co.jp> <20040325143319.GA873@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla Thunderbird 0.5 (Windows/20040207)
Ralf Baechle wrote:

On Thu, Mar 25, 2004 at 10:42:29PM +0900, Atsushi Nemoto wrote:

I noticed that reading from file with mmap sometimes return wrong data
on 2.4 kernel.

This is a test program to reproduce the problem.

This seems to be the same problem as reported by Peter Horton as while
ago; in his case that was with PIO IDE.

Looks like it.

The fix we're using on Cobalt's at the moment is below (required for 2.4.x and 2.6.x).

Fixing it this way fixes the problem with both page cache pages and swap pages.

For more details see the threads "Kernel 2.4.23 on Cobalt Qube2 - area of problem" and "Instability / caching problems on Qube 2 - solved ?" from December last year.

P.

diff -urN linux.cvs/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux.cvs/arch/mips/mm/c-r4k.c      Mon Jan 12 18:19:51 2004
+++ linux/arch/mips/mm/c-r4k.c  Sun Feb  1 13:35:55 2004
@@ -400,8 +400,10 @@
         * If there's no context yet, or the page isn't executable, no icache
         * flush is needed.
         */
+#ifndef CONFIG_MIPS_COBALT
        if (!(vma->vm_flags & VM_EXEC))
                return;
+#endif

        /*
         * Tricky ...  Because we don't know the virtual address we've got the
@@ -425,6 +427,11 @@
                r4k_blast_dcache_page(addr);
                ClearPageDcacheDirty(page);
        }
+
+#ifdef CONFIG_MIPS_COBALT
+       if (!(vma->vm_flags & VM_EXEC))
+               return;
+#endif

        /*
         * We're not sure of the virtual address(es) involved here, so



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