flush_anon_page for MIPS

flush_anon_page for MIPS

[Miklos Szeredi]

It seems that MIPS needs to implement flush_anon_page() for correct
operation of get_user_pages() on anonymous pages.

This function is already implemented in PARISC and ARM.  Also see
Documentation/cachetlb.txt.

Thanks,
Miklos

Re: flush_anon_page for MIPS

[Ralf Baechle]

On Thu, Mar 22, 2007 at 11:28:40PM +0100, Miklos Szeredi wrote:

> It seems that MIPS needs to implement flush_anon_page() for correct
> operation of get_user_pages() on anonymous pages.
> 
> This function is already implemented in PARISC and ARM.  Also see
> Documentation/cachetlb.txt.

**GRRRRR**

From <linux/highmem.h>:

#ifndef ARCH_HAS_FLUSH_ANON_PAGE
static inline void flush_anon_page(struct vm_area_struct *vma, struct page *page
, unsigned long vmaddr)
{
}
#endif

See why such stuff is happening?  Providing a default implemntation may be
fine for i.e. strcpy() where it's only about providing a better mouse
trap than the standard one in lib/string.c.  It's an awfully bad idea for
something that matters for correctness such as flush_anon_page() ...

Oh well, I'm looking into it.  Fortunately I've written reasonable
infrastructure during the previous round of the cache alias wars, so this
case should be reasonably simple to solve.  First cut of patch below.

The other thing I still need to understand is why nobody actually seems
to have triggered this bug on MIPS so far.  I suppose our implementation
of flush_dcache_page() may have done a successful job at papering it
which means there might be some performance getting lost there as well.

Was this one found by code inspection or actually triggered by like FUSE?

  Ralf

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c
index 31819c5..f565608 100644
--- a/arch/mips/mm/cache.c
+++ b/arch/mips/mm/cache.c
@@ -3,7 +3,8 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  *
- * Copyright (C) 1994 - 2003 by Ralf Baechle
+ * Copyright (C) 1994 - 2003, 07 by Ralf Baechle (ralf@linux-mips.org)
+ * Copyright (C) 2007 MIPS Technologies, Inc.
  */
 #include <linux/init.h>
 #include <linux/kernel.h>
@@ -88,6 +89,23 @@ void __flush_dcache_page(struct page *page)
 
 EXPORT_SYMBOL(__flush_dcache_page);
 
+void __flush_anon_page(struct vm_area_struct *vma, struct page *page,
+	unsigned long vmaddr)
+{
+	if (!cpu_has_dc_aliases)
+		return;
+
+	if (pages_do_alias((unsigned long)page_address(page), vmaddr)) {
+		void *kaddr;
+
+		kaddr = kmap_coherent(page, vmaddr);
+		flush_data_cache_page((unsigned long)kaddr);
+		kunmap_coherent(kaddr);
+	}
+}
+
+EXPORT_SYMBOL(__flush_anon_page);
+
 void __update_cache(struct vm_area_struct *vma, unsigned long address,
 	pte_t pte)
 {
diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
index 25abe91..e9951c0 100644
--- a/arch/mips/mm/init.c
+++ b/arch/mips/mm/init.c
@@ -123,7 +123,7 @@ static void __init kmap_coherent_init(void)
 static inline void kmap_coherent_init(void) {}
 #endif
 
-static inline void *kmap_coherent(struct page *page, unsigned long addr)
+void *kmap_coherent(struct page *page, unsigned long addr)
 {
 	enum fixed_addresses idx;
 	unsigned long vaddr, flags, entrylo;
@@ -177,7 +177,7 @@ static inline void *kmap_coherent(struct page *page, unsigned long addr)
 
 #define UNIQUE_ENTRYHI(idx) (CKSEG0 + ((idx) << (PAGE_SHIFT + 1)))
 
-static inline void kunmap_coherent(struct page *page)
+void kunmap_coherent(struct page *page)
 {
 #ifndef CONFIG_MIPS_MT_SMTC
 	unsigned int wired;
diff --git a/include/asm-mips/cacheflush.h b/include/asm-mips/cacheflush.h
index 0ddada3..1bd3310 100644
--- a/include/asm-mips/cacheflush.h
+++ b/include/asm-mips/cacheflush.h
@@ -48,6 +48,16 @@ static inline void flush_dcache_page(struct page *page)
 #define flush_dcache_mmap_lock(mapping)		do { } while (0)
 #define flush_dcache_mmap_unlock(mapping)	do { } while (0)
 
+#define ARCH_HAS_FLUSH_ANON_PAGE
+static inline void flush_anon_page(struct vm_area_struct *vma,
+	struct page *page, unsigned long vmaddr)
+{
+	extern void __flush_anon_page(struct vm_area_struct *vma,
+	                              struct page *, unsigned long);
+	if (PageAnon(page))
+		__flush_anon_page(vma, page, vmaddr);
+}
+
 static inline void flush_icache_page(struct vm_area_struct *vma,
 	struct page *page)
 {
@@ -86,4 +96,7 @@ extern void (*flush_data_cache_page)(unsigned long addr);
 /* Run kernel code uncached, useful for cache probing functions. */
 unsigned long __init run_uncached(void *func);
 
+extern void *kmap_coherent(struct page *page, unsigned long addr);
+extern void kunmap_coherent(struct page *page);
+
 #endif /* _ASM_CACHEFLUSH_H */

Re: flush_anon_page for MIPS

[Ralf Baechle]

On Thu, Mar 22, 2007 at 11:28:40PM +0100, Miklos Szeredi wrote:

> It seems that MIPS needs to implement flush_anon_page() for correct
> operation of get_user_pages() on anonymous pages.
> 
> This function is already implemented in PARISC and ARM.  Also see
> Documentation/cachetlb.txt.

**GRRRRR**

Re: flush_anon_page for MIPS

[Franck Bui-Huu]

Hi,

On 3/23/07, Ralf Baechle <ralf@linux-mips.org> wrote:
> The other thing I still need to understand is why nobody actually seems
> to have triggered this bug on MIPS so far.  I suppose our implementation
> of flush_dcache_page() may have done a successful job at papering it
> which means there might be some performance getting lost there as well.
>

Just to understand, doesn't all mappings of shared anonymous pages and
kernel addresses of them share the same cache lines ?

thanks,
-- 
               Franck

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Ralf Baechle [mailto:ralf@linux-mips.org] 
> Sent: Friday, March 23, 2007 10:20 AM
> To: Miklos Szeredi
> Cc: linux-mips@linux-mips.org; Ravi Pratap
> Subject: Re: flush_anon_page for MIPS
> 
> On Thu, Mar 22, 2007 at 11:28:40PM +0100, Miklos Szeredi wrote:
> 
> > It seems that MIPS needs to implement flush_anon_page() for correct
> > operation of get_user_pages() on anonymous pages.
> > 
> > This function is already implemented in PARISC and ARM.  Also see
> > Documentation/cachetlb.txt.
>
> Was this one found by code inspection or actually triggered 
> by like FUSE?

It was actually triggered by FUSE.


Ravi.

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Ralf Baechle [mailto:ralf@linux-mips.org] 
> Sent: Friday, March 23, 2007 10:20 AM
> To: Miklos Szeredi
> Cc: linux-mips@linux-mips.org; Ravi Pratap
> Subject: Re: flush_anon_page for MIPS
> 
> On Thu, Mar 22, 2007 at 11:28:40PM +0100, Miklos Szeredi wrote:
> 
> > It seems that MIPS needs to implement flush_anon_page() for correct
> > operation of get_user_pages() on anonymous pages.
> > 
> > This function is already implemented in PARISC and ARM.  Also see
> > Documentation/cachetlb.txt.
>
> Was this one found by code inspection or actually triggered 
> by like FUSE?

It was actually triggered by FUSE.


Ravi.

Re: flush_anon_page for MIPS

[Franck Bui-Huu]

On 3/23/07, Ralf Baechle <ralf@linux-mips.org> wrote:
> +#define ARCH_HAS_FLUSH_ANON_PAGE
> +static inline void flush_anon_page(struct vm_area_struct *vma,
> +       struct page *page, unsigned long vmaddr)
> +{
> +       extern void __flush_anon_page(struct vm_area_struct *vma,
> +                                     struct page *, unsigned long);
> +       if (PageAnon(page))
> +               __flush_anon_page(vma, page, vmaddr);
> +}
> +

Shouldn't you add a test against cpu_has_dc_aliases here and thus
avoid an useless call to __flush_anon_page() ?

-- 
               Franck

Re: flush_anon_page for MIPS

[Ralf Baechle]

On Fri, Mar 23, 2007 at 03:47:45PM +0100, Franck Bui-Huu wrote:

> On 3/23/07, Ralf Baechle <ralf@linux-mips.org> wrote:
> >The other thing I still need to understand is why nobody actually seems
> >to have triggered this bug on MIPS so far.  I suppose our implementation
> >of flush_dcache_page() may have done a successful job at papering it
> >which means there might be some performance getting lost there as well.
> >
> 
> Just to understand, doesn't all mappings of shared anonymous pages and
> kernel addresses of them share the same cache lines ?

That's true only for all userspace mappings and an anonymous page should
normally have only a single mapping per mm anyway.  But to make things
more complicated a page of course also has a kernel space address in
KSEG0 or XKPHYS and on a VIPT cache there we frequently have the case
where the user address and the kernel address would map to a different
cache line.

Let me illustrate this with a little example.  Assume we have a page at
physical address 0x5000, a page size of 4kB, an 8kB direct mapped cache
and 32-byte cache lines.  Then address bits 0..4 will be the byte index
into the cache line, address bits 5..12 will index the cache array.  So
now let's map our page into userspace, at address 0x12340000.  In KSEG0
it is accessible at 0x80005000.  Now, compute the cache index for both
addresses compare and curse ...

  Ralf

Re: flush_anon_page for MIPS

[Ralf Baechle]

On Fri, Mar 23, 2007 at 04:01:04PM +0100, Franck Bui-Huu wrote:
> Date:	Fri, 23 Mar 2007 16:01:04 +0100
> From:	"Franck Bui-Huu" <vagabon.xyz@gmail.com>
> To:	"Ralf Baechle" <ralf@linux-mips.org>
> Subject: Re: flush_anon_page for MIPS
> Cc:	"Miklos Szeredi" <miklos@szeredi.hu>, linux-mips@linux-mips.org,
> 	Ravi.Pratap@hillcrestlabs.com
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 3/23/07, Ralf Baechle <ralf@linux-mips.org> wrote:
> >+#define ARCH_HAS_FLUSH_ANON_PAGE
> >+static inline void flush_anon_page(struct vm_area_struct *vma,
> >+       struct page *page, unsigned long vmaddr)
> >+{
> >+       extern void __flush_anon_page(struct vm_area_struct *vma,
> >+                                     struct page *, unsigned long);
> >+       if (PageAnon(page))
> >+               __flush_anon_page(vma, page, vmaddr);
> >+}
> >+
> 
> Shouldn't you add a test against cpu_has_dc_aliases here and thus
> avoid an useless call to __flush_anon_page() ?

Yes, that's one of the things left to do.  On alias-free processors where
cpu_has_dc_aliases was defined to 0 in cpu-feature-overrides.h this will
result in the entire function call to be eleminated by the compiler.  Of
course that will still leave the unused body of __flush_anon_page around,
how sad ;)

  Ralf

Re: flush_anon_page for MIPS

[Atsushi Nemoto]

On Fri, 23 Mar 2007 10:51:32 -0400, "Ravi Pratap" <Ravi.Pratap@hillcrestlabs.com> wrote:
> > Was this one found by code inspection or actually triggered 
> > by like FUSE?
> 
> It was actually triggered by FUSE.

Could you point us any good (simple, easy to install, independent from
any special device) FUSE program to test it?

---
Atsushi Nemoto

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Atsushi Nemoto [mailto:anemo@mba.ocn.ne.jp] 
> Sent: Friday, March 23, 2007 11:42 AM
> To: Ravi Pratap
> Cc: ralf@linux-mips.org; miklos@szeredi.hu; linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Fri, 23 Mar 2007 10:51:32 -0400, "Ravi Pratap" 
> <Ravi.Pratap@hillcrestlabs.com> wrote:
> > > Was this one found by code inspection or actually 
> triggered by like 
> > > FUSE?
> > 
> > It was actually triggered by FUSE.
> 
> Could you point us any good (simple, easy to install, 
> independent from any special device) FUSE program to test it?

The standard FUSE hello program triggers the bug every single time. All
you have to do is follow the example on the FUSE web page:
http://fuse.sourceforge.net 

~/fuse/example$ mkdir /tmp/fuse
~/fuse/example$ ./hello /tmp/fuse
~/fuse/example$ ls -l /tmp/fuse
total 0
-r--r--r--  1 root root 13 Jan  1  1970 hello
~/fuse/example$ cat /tmp/fuse/hello
Hello World!
~/fuse/example$ fusermount -u /tmp/fuse
~/fuse/example$


It hangs when you do ls -l /tmp/fuse, in the above example.


HTH,

Ravi.

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Atsushi Nemoto [mailto:anemo@mba.ocn.ne.jp] 
> Sent: Friday, March 23, 2007 11:42 AM
> To: Ravi Pratap
> Cc: ralf@linux-mips.org; miklos@szeredi.hu; linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Fri, 23 Mar 2007 10:51:32 -0400, "Ravi Pratap" 
> <Ravi.Pratap@hillcrestlabs.com> wrote:
> > > Was this one found by code inspection or actually 
> triggered by like 
> > > FUSE?
> > 
> > It was actually triggered by FUSE.
> 
> Could you point us any good (simple, easy to install, 
> independent from any special device) FUSE program to test it?

The standard FUSE hello program triggers the bug every single time. All
you have to do is follow the example on the FUSE web page:
http://fuse.sourceforge.net 

~/fuse/example$ mkdir /tmp/fuse
~/fuse/example$ ./hello /tmp/fuse
~/fuse/example$ ls -l /tmp/fuse
total 0
-r--r--r--  1 root root 13 Jan  1  1970 hello
~/fuse/example$ cat /tmp/fuse/hello
Hello World!
~/fuse/example$ fusermount -u /tmp/fuse
~/fuse/example$


It hangs when you do ls -l /tmp/fuse, in the above example.


HTH,

Ravi.

Re: flush_anon_page for MIPS

[Atsushi Nemoto]

On Fri, 23 Mar 2007 11:47:20 -0400, "Ravi Pratap" <Ravi.Pratap@hillcrestlabs.com> wrote:
> The standard FUSE hello program triggers the bug every single time. All
> you have to do is follow the example on the FUSE web page:
> http://fuse.sourceforge.net 

Thanks!  I'll try it (with Ralf's patch) next week.
---
Atsushi Nemoto

Re: flush_anon_page for MIPS

[Ralf Baechle]

On Fri, Mar 23, 2007 at 11:47:20AM -0400, Ravi Pratap wrote:

> The standard FUSE hello program triggers the bug every single time. All
> you have to do is follow the example on the FUSE web page:
> http://fuse.sourceforge.net 
> 
> ~/fuse/example$ mkdir /tmp/fuse
> ~/fuse/example$ ./hello /tmp/fuse
> ~/fuse/example$ ls -l /tmp/fuse
> total 0
> -r--r--r--  1 root root 13 Jan  1  1970 hello
> ~/fuse/example$ cat /tmp/fuse/hello
> Hello World!
> ~/fuse/example$ fusermount -u /tmp/fuse
> ~/fuse/example$
> 
> 
> It hangs when you do ls -l /tmp/fuse, in the above example.

What processor does it fail on?

  Ralf

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Ralf Baechle [mailto:ralf@linux-mips.org] 
> Sent: Friday, March 23, 2007 11:57 AM
> To: Ravi Pratap
> Cc: Atsushi Nemoto; miklos@szeredi.hu; linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Fri, Mar 23, 2007 at 11:47:20AM -0400, Ravi Pratap wrote:
> 
> > The standard FUSE hello program triggers the bug every single time. 
> > All you have to do is follow the example on the FUSE web page:
> > http://fuse.sourceforge.net
> > 
> > ~/fuse/example$ mkdir /tmp/fuse
> > ~/fuse/example$ ./hello /tmp/fuse
> > ~/fuse/example$ ls -l /tmp/fuse
> > total 0
> > -r--r--r--  1 root root 13 Jan  1  1970 hello ~/fuse/example$ cat 
> > /tmp/fuse/hello Hello World!
> > ~/fuse/example$ fusermount -u /tmp/fuse ~/fuse/example$
> > 
> > 
> > It hangs when you do ls -l /tmp/fuse, in the above example.
> 
> What processor does it fail on?

# cat /proc/cpuinfo
system type             : Sigma Designs TangoX
processor               : 0
cpu model               : MIPS 4KEc V6.8
BogoMIPS                : 299.00
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes
ASEs implemented        : mips16
VCED exceptions         : not available
VCEI exceptions         : not available

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Ralf Baechle [mailto:ralf@linux-mips.org] 
> Sent: Friday, March 23, 2007 11:57 AM
> To: Ravi Pratap
> Cc: Atsushi Nemoto; miklos@szeredi.hu; linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Fri, Mar 23, 2007 at 11:47:20AM -0400, Ravi Pratap wrote:
> 
> > The standard FUSE hello program triggers the bug every single time. 
> > All you have to do is follow the example on the FUSE web page:
> > http://fuse.sourceforge.net
> > 
> > ~/fuse/example$ mkdir /tmp/fuse
> > ~/fuse/example$ ./hello /tmp/fuse
> > ~/fuse/example$ ls -l /tmp/fuse
> > total 0
> > -r--r--r--  1 root root 13 Jan  1  1970 hello ~/fuse/example$ cat 
> > /tmp/fuse/hello Hello World!
> > ~/fuse/example$ fusermount -u /tmp/fuse ~/fuse/example$
> > 
> > 
> > It hangs when you do ls -l /tmp/fuse, in the above example.
> 
> What processor does it fail on?

# cat /proc/cpuinfo
system type             : Sigma Designs TangoX
processor               : 0
cpu model               : MIPS 4KEc V6.8
BogoMIPS                : 299.00
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes
ASEs implemented        : mips16
VCED exceptions         : not available
VCEI exceptions         : not available

RE: flush_anon_page for MIPS

[Maxime Bizon]

On Fri, 2007-03-23 at 11:59 -0400, Ravi Pratap wrote:

> > What processor does it fail on?

> # cat /proc/cpuinfo
> system type             : Sigma Designs TangoX

Same processor, same problem:

Primary instruction cache 16kB, physically tagged, 2-way, linesize 16 bytes.
Primary data cache 16kB, 2-way, linesize 16 bytes.

-- 
Maxime

Re: flush_anon_page for MIPS

[Franck Bui-Huu]

On 3/23/07, Ravi Pratap <Ravi.Pratap@hillcrestlabs.com> wrote:
> > From: Ralf Baechle [mailto:ralf@linux-mips.org]
> > What processor does it fail on?
>
> # cat /proc/cpuinfo
> system type             : Sigma Designs TangoX
> processor               : 0
> cpu model               : MIPS 4KEc V6.8

Does this cpu have cache aliasings ?

How is configured the data cache ? Could you show the 'dmesg' output ?
-- 
               Franck

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Franck Bui-Huu [mailto:vagabon.xyz@gmail.com] 
> Sent: Friday, March 23, 2007 12:13 PM
> To: Ravi Pratap
> Cc: Ralf Baechle; Atsushi Nemoto; miklos@szeredi.hu; 
> linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On 3/23/07, Ravi Pratap <Ravi.Pratap@hillcrestlabs.com> wrote:
> > > From: Ralf Baechle [mailto:ralf@linux-mips.org] What 
> processor does 
> > > it fail on?
> >
> > # cat /proc/cpuinfo
> > system type             : Sigma Designs TangoX
> > processor               : 0
> > cpu model               : MIPS 4KEc V6.8
> 
> Does this cpu have cache aliasings ?
> 
> How is configured the data cache ? Could you show the 'dmesg' output ?

Here you go. Let me know if you want more:


Configured for SMP8634 (revision ES6/RevA), detected SMP8634 (revision
ES7/RevB).
SMP863x/SMP864x Enabled Devices under Linux/XENV 0x48000000 = 0x00023efe
 BM/IDE PCIHost Ethernet IR FIP I2CM I2CS USB PCIDev1 PCIDev2 PCIDev3
PCIDev4 SCARD
Valid MEMCFG found at 0x10000fc0.
CPU revision is: 00019068
Determined physical RAM map:
 memory: 03fe0000 @ 10020000 (usable)
User-defined physical RAM map:
 memory: 04fe0000 @ 10020000 (usable)
On node 0 totalpages: 86016
  DMA zone: 86016 pages, LIFO batch:15
  DMA32 zone: 0 pages, LIFO batch:0
  Normal zone: 0 pages, LIFO batch:0
  HighMem zone: 0 pages, LIFO batch:0
Built 1 zonelists
Kernel command line: mem=80m
Primary instruction cache 16kB, physically tagged, 2-way, linesize 16
bytes.
Primary data cache 16kB, 2-way, linesize 16 bytes.
Synthesized TLB refill handler (20 instructions).
Synthesized TLB load handler fastpath (32 instructions).
Synthesized TLB store handler fastpath (32 instructions).
Synthesized TLB modify handler fastpath (31 instructions).
PID hash table entries: 2048 (order: 11, 32768 bytes)
Using 150.750 MHz high precision timer.
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 71808k/81792k available (2756k kernel code, 9968k reserved, 408k
data, 3532k init, 0k highmem)
Calibrating delay loop... 299.00 BogoMIPS (lpj=149504)
Mount-cache hash table entries: 512
Checking for 'wait' instruction...  available.
NET: Registered protocol family 16
tangox: creating TLB mapping for 0x20000000 at 0xc0000000, size
0x08000000.
PCI: Initializing SMP863x/SMP864x PCI host controller
PCI: Remapped PCI I/O space 0x58000000 to 0xc8020000, size 64 kB
PCI: Remapped PCI config space 0x50000000 to 0xc8004000, size 10 kB
PCI: Configured SMP863x/SMP864x as PCI slave with 128MB PCI memory
PCI: Region size is 16384KB
PCI: Map DMA memory 0x10020000-0x15000000 for PCI at 0x12000000
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
Created /proc/cpucache_info entry.
JFS: nTxBlock = 561, nTxLock = 4489
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
Generic RTC Driver v1.07
Software Watchdog Timer: 0.07 initialized. soft_noboot=0 soft_margin=60
sec (nowayout= 0)
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing
disabled
serial8250: ttyS0 at MMIO 0x0 (irq = 9) is a 16550A
tangox_enet: ethernet driver for SMP863x/SMP864x internal mac
tangox_enet: detected phy at address 0x01
tangox_enet: mac address 00:16:e8:a9:4c:d5
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with
idebus=xx
ide0: SMP863x/SMP864x Bus Mastering IDE controller
Probing IDE interface ide0...
hda: ST3120213A, ATA DISK drive
hda: no 80 conductors cable, falling back to lower udma mode
hda: set to Ultra DMA mode 2
ide0: DMA enabled for ATA DISK hda
ide0 at 0x223c0-0x223c7,0x22398 on irq 26
hda: max request size: 128KiB
hda: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=16383/255/63,
UDMA(33)
hda: cache flushes supported
 hda: hda1 hda2 hda3
physmap flash device CS2: 400000 at 48000000
CS2: Physically mapped flash: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
CS2: Physically mapped flash: CFI does not contain boot bank location.
Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
CS2: flash size mismatched, re-do probing/initialization.
physmap flash device CS2: 4000000 at 48000000 (remapped c8100000)
CS2: Physically mapped flash: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
CS2: Physically mapped flash: CFI does not contain boot bank location.
Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Using physmap partition definition
Adding partition #1-#5
Creating 5 MTD partitions on "CS2: Physically mapped flash":
0x00000000-0x00020000 : "CS2-Part1"
0x00020000-0x00040000 : "CS2-Part2"
0x00040000-0x00080000 : "CS2-Part3"
0x00080000-0x003e0000 : "CS2-Part4"
0x003e0000-0x00400000 : "CS2-Part5"
physmap flash device CS3: 4000000 at 4c000000
CFI: Found no CS3: Physically mapped flash device at location zero
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver
(PCI)
USB Universal Host Controller Interface driver v2.3
driver tangox-ehci-hcd, 10 Dec 2004
TangoX USB initializing...
tangox-ehci-hcd tangox-ehci-hcd: TangoX USB 2.0
tangox-ehci-hcd tangox-ehci-hcd: new USB bus registered, assigned bus
number 1
tangox-ehci-hcd tangox-ehci-hcd: irq 48, io mem 0xa0021500
tangox-ehci-hcd tangox-ehci-hcd: USB 0.0 started, EHCI 1.00, driver 10
Dec 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
TangoX USB was initialized.
Initializing TangoX USB OHCI Controller Polling mode, Membase=0xa0021500
Status=0x5
tangox-ohci-hcd tangox-ohci-hcd: USB Host Controller
tangox-ohci-hcd tangox-ohci-hcd: new USB bus registered, assigned bus
number 2
tangox-ohci-hcd tangox-ohci-hcd: io mem 0xa0021500
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usb 2-2: new low speed USB device using tangox-ohci-hcd and address 2
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Freeing unused kernel memory: 3532k freed
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Franck Bui-Huu [mailto:vagabon.xyz@gmail.com] 
> Sent: Friday, March 23, 2007 12:13 PM
> To: Ravi Pratap
> Cc: Ralf Baechle; Atsushi Nemoto; miklos@szeredi.hu; 
> linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On 3/23/07, Ravi Pratap <Ravi.Pratap@hillcrestlabs.com> wrote:
> > > From: Ralf Baechle [mailto:ralf@linux-mips.org] What 
> processor does 
> > > it fail on?
> >
> > # cat /proc/cpuinfo
> > system type             : Sigma Designs TangoX
> > processor               : 0
> > cpu model               : MIPS 4KEc V6.8
> 
> Does this cpu have cache aliasings ?
> 
> How is configured the data cache ? Could you show the 'dmesg' output ?

Here you go. Let me know if you want more:


Configured for SMP8634 (revision ES6/RevA), detected SMP8634 (revision
ES7/RevB).
SMP863x/SMP864x Enabled Devices under Linux/XENV 0x48000000 = 0x00023efe
 BM/IDE PCIHost Ethernet IR FIP I2CM I2CS USB PCIDev1 PCIDev2 PCIDev3
PCIDev4 SCARD
Valid MEMCFG found at 0x10000fc0.
CPU revision is: 00019068
Determined physical RAM map:
 memory: 03fe0000 @ 10020000 (usable)
User-defined physical RAM map:
 memory: 04fe0000 @ 10020000 (usable)
On node 0 totalpages: 86016
  DMA zone: 86016 pages, LIFO batch:15
  DMA32 zone: 0 pages, LIFO batch:0
  Normal zone: 0 pages, LIFO batch:0
  HighMem zone: 0 pages, LIFO batch:0
Built 1 zonelists
Kernel command line: mem=80m
Primary instruction cache 16kB, physically tagged, 2-way, linesize 16
bytes.
Primary data cache 16kB, 2-way, linesize 16 bytes.
Synthesized TLB refill handler (20 instructions).
Synthesized TLB load handler fastpath (32 instructions).
Synthesized TLB store handler fastpath (32 instructions).
Synthesized TLB modify handler fastpath (31 instructions).
PID hash table entries: 2048 (order: 11, 32768 bytes)
Using 150.750 MHz high precision timer.
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 71808k/81792k available (2756k kernel code, 9968k reserved, 408k
data, 3532k init, 0k highmem)
Calibrating delay loop... 299.00 BogoMIPS (lpj=149504)
Mount-cache hash table entries: 512
Checking for 'wait' instruction...  available.
NET: Registered protocol family 16
tangox: creating TLB mapping for 0x20000000 at 0xc0000000, size
0x08000000.
PCI: Initializing SMP863x/SMP864x PCI host controller
PCI: Remapped PCI I/O space 0x58000000 to 0xc8020000, size 64 kB
PCI: Remapped PCI config space 0x50000000 to 0xc8004000, size 10 kB
PCI: Configured SMP863x/SMP864x as PCI slave with 128MB PCI memory
PCI: Region size is 16384KB
PCI: Map DMA memory 0x10020000-0x15000000 for PCI at 0x12000000
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
Created /proc/cpucache_info entry.
JFS: nTxBlock = 561, nTxLock = 4489
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
Generic RTC Driver v1.07
Software Watchdog Timer: 0.07 initialized. soft_noboot=0 soft_margin=60
sec (nowayout= 0)
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing
disabled
serial8250: ttyS0 at MMIO 0x0 (irq = 9) is a 16550A
tangox_enet: ethernet driver for SMP863x/SMP864x internal mac
tangox_enet: detected phy at address 0x01
tangox_enet: mac address 00:16:e8:a9:4c:d5
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with
idebus=xx
ide0: SMP863x/SMP864x Bus Mastering IDE controller
Probing IDE interface ide0...
hda: ST3120213A, ATA DISK drive
hda: no 80 conductors cable, falling back to lower udma mode
hda: set to Ultra DMA mode 2
ide0: DMA enabled for ATA DISK hda
ide0 at 0x223c0-0x223c7,0x22398 on irq 26
hda: max request size: 128KiB
hda: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=16383/255/63,
UDMA(33)
hda: cache flushes supported
 hda: hda1 hda2 hda3
physmap flash device CS2: 400000 at 48000000
CS2: Physically mapped flash: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
CS2: Physically mapped flash: CFI does not contain boot bank location.
Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
CS2: flash size mismatched, re-do probing/initialization.
physmap flash device CS2: 4000000 at 48000000 (remapped c8100000)
CS2: Physically mapped flash: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
CS2: Physically mapped flash: CFI does not contain boot bank location.
Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Using physmap partition definition
Adding partition #1-#5
Creating 5 MTD partitions on "CS2: Physically mapped flash":
0x00000000-0x00020000 : "CS2-Part1"
0x00020000-0x00040000 : "CS2-Part2"
0x00040000-0x00080000 : "CS2-Part3"
0x00080000-0x003e0000 : "CS2-Part4"
0x003e0000-0x00400000 : "CS2-Part5"
physmap flash device CS3: 4000000 at 4c000000
CFI: Found no CS3: Physically mapped flash device at location zero
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver
(PCI)
USB Universal Host Controller Interface driver v2.3
driver tangox-ehci-hcd, 10 Dec 2004
TangoX USB initializing...
tangox-ehci-hcd tangox-ehci-hcd: TangoX USB 2.0
tangox-ehci-hcd tangox-ehci-hcd: new USB bus registered, assigned bus
number 1
tangox-ehci-hcd tangox-ehci-hcd: irq 48, io mem 0xa0021500
tangox-ehci-hcd tangox-ehci-hcd: USB 0.0 started, EHCI 1.00, driver 10
Dec 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
TangoX USB was initialized.
Initializing TangoX USB OHCI Controller Polling mode, Membase=0xa0021500
Status=0x5
tangox-ohci-hcd tangox-ohci-hcd: USB Host Controller
tangox-ohci-hcd tangox-ohci-hcd: new USB bus registered, assigned bus
number 2
tangox-ohci-hcd tangox-ohci-hcd: io mem 0xa0021500
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usb 2-2: new low speed USB device using tangox-ohci-hcd and address 2
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Freeing unused kernel memory: 3532k freed
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1

Re: flush_anon_page for MIPS

[Miklos Szeredi]

Ralf,

Thanks for looking into this.

> See why such stuff is happening?  Providing a default implemntation may be
> fine for i.e. strcpy() where it's only about providing a better mouse
> trap than the standard one in lib/string.c.  It's an awfully bad idea for
> something that matters for correctness such as flush_anon_page() ...

Well, James Bottomley discussed this approach on linux-arch back then,
so you could have raised objections.

I don't like this whole flush_anon_page() approach, but nobody
(including me) seems to be interested enough in finding a better one ;)

Miklos

Re: flush_anon_page for MIPS

[Ralf Baechle]

On Fri, Mar 23, 2007 at 11:47:20AM -0400, Ravi Pratap wrote:

> ~/fuse/example$ mkdir /tmp/fuse
> ~/fuse/example$ ./hello /tmp/fuse
> ~/fuse/example$ ls -l /tmp/fuse
> total 0
> -r--r--r--  1 root root 13 Jan  1  1970 hello
> ~/fuse/example$ cat /tmp/fuse/hello
> Hello World!
> ~/fuse/example$ fusermount -u /tmp/fuse
> ~/fuse/example$
> 
> 
> It hangs when you do ls -l /tmp/fuse, in the above example.

Yes, that's perfectly reproducable here (running a VSMP kernel on a 34K).
So the fix I posted earlier was good but I did a few tweaks to it anyway.
Will commit to all 2.6 -stable branch and master later.

  Ralf

Re: flush_anon_page for MIPS

[Franck Bui-Huu]

On 3/23/07, Ralf Baechle <ralf@linux-mips.org> wrote:
> course that will still leave the unused body of __flush_anon_page around,
> how sad ;)
>

At this point,  ISTR there are some tools which can be used to remove dead code.
-- 
               Franck

Re: flush_anon_page for MIPS

[Franck Bui-Huu]

On 3/23/07, Ralf Baechle <ralf@linux-mips.org> wrote:
> Let me illustrate this with a little example.  Assume we have a page at
> physical address 0x5000, a page size of 4kB, an 8kB direct mapped cache
> and 32-byte cache lines.  Then address bits 0..4 will be the byte index
> into the cache line, address bits 5..12 will index the cache array.  So
> now let's map our page into userspace, at address 0x12340000.  In KSEG0
> it is accessible at 0x80005000.  Now, compute the cache index for both
> addresses compare and curse ...
>

Yes but since the kernel page address is fixed, why not choosing
userspace page addresses to share the same kernel cache index ?
-- 
               Franck

Re: flush_anon_page for MIPS

[Ralf Baechle]

On Fri, Mar 23, 2007 at 10:00:00PM +0100, Franck Bui-Huu wrote:

> On 3/23/07, Ralf Baechle <ralf@linux-mips.org> wrote:
> >Let me illustrate this with a little example.  Assume we have a page at
> >physical address 0x5000, a page size of 4kB, an 8kB direct mapped cache
> >and 32-byte cache lines.  Then address bits 0..4 will be the byte index
> >into the cache line, address bits 5..12 will index the cache array.  So
> >now let's map our page into userspace, at address 0x12340000.  In KSEG0
> >it is accessible at 0x80005000.  Now, compute the cache index for both
> >addresses compare and curse ...
> >
> 
> Yes but since the kernel page address is fixed, why not choosing
> userspace page addresses to share the same kernel cache index ?

That would require turning the memory allocator upside down to support
allocation of pages of a certain "color" which due to memory fragmentation
issues is seriously non-trivial.  Some UNIX variants do this scheme but
it doesn't come for free either and anyway, so far Linus' answer has been
a clear no.

  Ralf

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Ralf Baechle [mailto:ralf@linux-mips.org] 
> Sent: Friday, March 23, 2007 3:06 PM
> To: Ravi Pratap
> Cc: Atsushi Nemoto; miklos@szeredi.hu; linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Fri, Mar 23, 2007 at 11:47:20AM -0400, Ravi Pratap wrote:
> 
> > ~/fuse/example$ mkdir /tmp/fuse
> > ~/fuse/example$ ./hello /tmp/fuse
> > ~/fuse/example$ ls -l /tmp/fuse
> > total 0
> > -r--r--r--  1 root root 13 Jan  1  1970 hello
> > ~/fuse/example$ cat /tmp/fuse/hello
> > Hello World!
> > ~/fuse/example$ fusermount -u /tmp/fuse
> > ~/fuse/example$
> > 
> > 
> > It hangs when you do ls -l /tmp/fuse, in the above example.
> 
> Yes, that's perfectly reproducable here (running a VSMP 
> kernel on a 34K).
> So the fix I posted earlier was good but I did a few tweaks 
> to it anyway.
> Will commit to all 2.6 -stable branch and master later.


Thanks so much! Will this go into 2.6.15 by any chance?


Ravi.

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Ralf Baechle [mailto:ralf@linux-mips.org] 
> Sent: Friday, March 23, 2007 3:06 PM
> To: Ravi Pratap
> Cc: Atsushi Nemoto; miklos@szeredi.hu; linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Fri, Mar 23, 2007 at 11:47:20AM -0400, Ravi Pratap wrote:
> 
> > ~/fuse/example$ mkdir /tmp/fuse
> > ~/fuse/example$ ./hello /tmp/fuse
> > ~/fuse/example$ ls -l /tmp/fuse
> > total 0
> > -r--r--r--  1 root root 13 Jan  1  1970 hello
> > ~/fuse/example$ cat /tmp/fuse/hello
> > Hello World!
> > ~/fuse/example$ fusermount -u /tmp/fuse
> > ~/fuse/example$
> > 
> > 
> > It hangs when you do ls -l /tmp/fuse, in the above example.
> 
> Yes, that's perfectly reproducable here (running a VSMP 
> kernel on a 34K).
> So the fix I posted earlier was good but I did a few tweaks 
> to it anyway.
> Will commit to all 2.6 -stable branch and master later.


Thanks so much! Will this go into 2.6.15 by any chance?


Ravi.

Re: flush_anon_page for MIPS

[Ralf Baechle]

On Fri, Mar 23, 2007 at 06:17:25PM -0400, Ravi Pratap wrote:

> > Yes, that's perfectly reproducable here (running a VSMP 
> > kernel on a 34K).
> > So the fix I posted earlier was good but I did a few tweaks 
> > to it anyway.
> > Will commit to all 2.6 -stable branch and master later.
> 
> 
> Thanks so much! Will this go into 2.6.15 by any chance?

I don't recall that there every has been such a kernel release ;-)

But seriously, 2.6.15 is as dead as Tutankhamun.  I've never maintained
a 2.6.15-stable branch nor does anybody else still seem to be interested in
wasting his time on it.  And anyway flush_anon_page was only introduced in
2.6.17, so I've only fixed 2.6.17-stable and up.

  Ralf

Re: flush_anon_page for MIPS

[David Daney]

Ralf Baechle wrote:
> On Fri, Mar 23, 2007 at 06:17:25PM -0400, Ravi Pratap wrote:
> 
>>> Yes, that's perfectly reproducable here (running a VSMP 
>>> kernel on a 34K).
>>> So the fix I posted earlier was good but I did a few tweaks 
>>> to it anyway.
>>> Will commit to all 2.6 -stable branch and master later.
>>
>> Thanks so much! Will this go into 2.6.15 by any chance?
> 
> I don't recall that there every has been such a kernel release ;-)
> 
> But seriously, 2.6.15 is as dead as Tutankhamun.

Some chip vendors only support that version, so I am assuming that that 
was the reason for the question.

It is a classic case of what happens when people do ports that are not 
merged.  They say it is good enough as is and then never move forward or 
fix bugs.

The good news I guess is that we have the source, so we could forward 
port it if we were really motivated.

David Daney

Re: flush_anon_page for MIPS

[Atsushi Nemoto]

On Sat, 24 Mar 2007 00:50:29 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> > The standard FUSE hello program triggers the bug every single time. All
> > you have to do is follow the example on the FUSE web page:
> > http://fuse.sourceforge.net 
> 
> Thanks!  I'll try it (with Ralf's patch) next week.

I confirmed current git tree works fine for me.  Thanks.
---
Atsushi Nemoto

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: David Daney [mailto:ddaney@avtrex.com] 
> Sent: Friday, March 23, 2007 8:03 PM
> To: Ralf Baechle
> Cc: Ravi Pratap; Atsushi Nemoto; miklos@szeredi.hu; 
> linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> Ralf Baechle wrote:
> > On Fri, Mar 23, 2007 at 06:17:25PM -0400, Ravi Pratap wrote:
> > 
> >>> Yes, that's perfectly reproducable here (running a VSMP 
> kernel on a 
> >>> 34K).
> >>> So the fix I posted earlier was good but I did a few tweaks to it 
> >>> anyway.
> >>> Will commit to all 2.6 -stable branch and master later.
> >>
> >> Thanks so much! Will this go into 2.6.15 by any chance?
> > 
> > I don't recall that there every has been such a kernel release ;-)
> > 
> > But seriously, 2.6.15 is as dead as Tutankhamun.
> 
> Some chip vendors only support that version, so I am assuming 
> that that was the reason for the question.

That's correct, actually :-)

> It is a classic case of what happens when people do ports 
> that are not merged.  They say it is good enough as is and 
> then never move forward or fix bugs.

True, and I don't know why these vendors do it. I wish too that they
didn't.


> The good news I guess is that we have the source, so we could 
> forward port it if we were really motivated.

Yes, but isn't it a lot of work considering the lack of a
flush_anon_page in 2.6.15?


Ravi.

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: David Daney [mailto:ddaney@avtrex.com] 
> Sent: Friday, March 23, 2007 8:03 PM
> To: Ralf Baechle
> Cc: Ravi Pratap; Atsushi Nemoto; miklos@szeredi.hu; 
> linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> Ralf Baechle wrote:
> > On Fri, Mar 23, 2007 at 06:17:25PM -0400, Ravi Pratap wrote:
> > 
> >>> Yes, that's perfectly reproducable here (running a VSMP 
> kernel on a 
> >>> 34K).
> >>> So the fix I posted earlier was good but I did a few tweaks to it 
> >>> anyway.
> >>> Will commit to all 2.6 -stable branch and master later.
> >>
> >> Thanks so much! Will this go into 2.6.15 by any chance?
> > 
> > I don't recall that there every has been such a kernel release ;-)
> > 
> > But seriously, 2.6.15 is as dead as Tutankhamun.
> 
> Some chip vendors only support that version, so I am assuming 
> that that was the reason for the question.

That's correct, actually :-)

> It is a classic case of what happens when people do ports 
> that are not merged.  They say it is good enough as is and 
> then never move forward or fix bugs.

True, and I don't know why these vendors do it. I wish too that they
didn't.


> The good news I guess is that we have the source, so we could 
> forward port it if we were really motivated.

Yes, but isn't it a lot of work considering the lack of a
flush_anon_page in 2.6.15?


Ravi.

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Atsushi Nemoto [mailto:anemo@mba.ocn.ne.jp] 
> Sent: Monday, March 26, 2007 9:32 AM
> To: Ravi Pratap
> Cc: ralf@linux-mips.org; miklos@szeredi.hu; linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Sat, 24 Mar 2007 00:50:29 +0900 (JST), Atsushi Nemoto 
> <anemo@mba.ocn.ne.jp> wrote:
> > > The standard FUSE hello program triggers the bug every 
> single time. 
> > > All you have to do is follow the example on the FUSE web page:
> > > http://fuse.sourceforge.net
> > 
> > Thanks!  I'll try it (with Ralf's patch) next week.
> 
> I confirmed current git tree works fine for me.  Thanks.

Great! Pardon my ignorance in asking this question but when will I be
able to grab a stable release that includes this change?


Thanks,

Ravi.

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Atsushi Nemoto [mailto:anemo@mba.ocn.ne.jp] 
> Sent: Monday, March 26, 2007 9:32 AM
> To: Ravi Pratap
> Cc: ralf@linux-mips.org; miklos@szeredi.hu; linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Sat, 24 Mar 2007 00:50:29 +0900 (JST), Atsushi Nemoto 
> <anemo@mba.ocn.ne.jp> wrote:
> > > The standard FUSE hello program triggers the bug every 
> single time. 
> > > All you have to do is follow the example on the FUSE web page:
> > > http://fuse.sourceforge.net
> > 
> > Thanks!  I'll try it (with Ralf's patch) next week.
> 
> I confirmed current git tree works fine for me.  Thanks.

Great! Pardon my ignorance in asking this question but when will I be
able to grab a stable release that includes this change?


Thanks,

Ravi.

Re: flush_anon_page for MIPS

[Ralf Baechle]

On Mon, Mar 26, 2007 at 09:33:10AM -0400, Ravi Pratap wrote:

> > >> Thanks so much! Will this go into 2.6.15 by any chance?
> > > 
> > > I don't recall that there every has been such a kernel release ;-)
> > > 
> > > But seriously, 2.6.15 is as dead as Tutankhamun.
> > 
> > Some chip vendors only support that version, so I am assuming 
> > that that was the reason for the question.
> 
> That's correct, actually :-)
> 
> > It is a classic case of what happens when people do ports 
> > that are not merged.  They say it is good enough as is and 
> > then never move forward or fix bugs.
> 
> True, and I don't know why these vendors do it. I wish too that they
> didn't.

Talk to them.  Be prepared to reiterate.

> > The good news I guess is that we have the source, so we could 
> > forward port it if we were really motivated.
> 
> Yes, but isn't it a lot of work considering the lack of a
> flush_anon_page in 2.6.15?

David wrote about forward porting the patches in your vendor kernel
to a more modern kernel.  That would require some work but the
flush_anon_page() thing would be the least of your worries.

Otherwise, you'd need to backport the about following changesets into
your kernel to get flush_anon_page:

03beb07664d768db97bf454ae5c9581cd4737bb4
df7c814ea6385fea8ccf54c80ec78326f78b743e
f036773e8760a79ad9fdeea6665f86d3493d40d1
4c40981a5c0fe1ee5c755a55a4a8e5e3527f0bca

  Ralf

Re: flush_anon_page for MIPS

[Ralf Baechle]

On Mon, Mar 26, 2007 at 09:36:33AM -0400, Ravi Pratap wrote:

> > I confirmed current git tree works fine for me.  Thanks.
> 
> Great! Pardon my ignorance in asking this question but when will I be
> able to grab a stable release that includes this change?

Yes, at this time either directly from the lmo git tree or the
linux-2.6.20.4 tarball also from lmo.

  Ralf

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Ralf Baechle [mailto:ralf@linux-mips.org] 
> Sent: Monday, March 26, 2007 10:06 AM
> To: Ravi Pratap
> Cc: David Daney; Atsushi Nemoto; miklos@szeredi.hu; 
> linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Mon, Mar 26, 2007 at 09:33:10AM -0400, Ravi Pratap wrote:
> 
> > 
> > Yes, but isn't it a lot of work considering the lack of a 
> > flush_anon_page in 2.6.15?
> 
> David wrote about forward porting the patches in your vendor 
> kernel to a more modern kernel.  That would require some work but the
> flush_anon_page() thing would be the least of your worries.
> 
> Otherwise, you'd need to backport the about following 
> changesets into your kernel to get flush_anon_page:
> 
> 03beb07664d768db97bf454ae5c9581cd4737bb4
> df7c814ea6385fea8ccf54c80ec78326f78b743e
> f036773e8760a79ad9fdeea6665f86d3493d40d1
> 4c40981a5c0fe1ee5c755a55a4a8e5e3527f0bca
> 

Thanks for the info. I think I'm going to go with backporting these
changesets for now while still talking to the vendors about upgrading
their kernel. The problem is that these guys are just notoriously slow
and we have work to get done :-)


Ravi.

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Ralf Baechle [mailto:ralf@linux-mips.org] 
> Sent: Monday, March 26, 2007 10:06 AM
> To: Ravi Pratap
> Cc: David Daney; Atsushi Nemoto; miklos@szeredi.hu; 
> linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Mon, Mar 26, 2007 at 09:33:10AM -0400, Ravi Pratap wrote:
> 
> > 
> > Yes, but isn't it a lot of work considering the lack of a 
> > flush_anon_page in 2.6.15?
> 
> David wrote about forward porting the patches in your vendor 
> kernel to a more modern kernel.  That would require some work but the
> flush_anon_page() thing would be the least of your worries.
> 
> Otherwise, you'd need to backport the about following 
> changesets into your kernel to get flush_anon_page:
> 
> 03beb07664d768db97bf454ae5c9581cd4737bb4
> df7c814ea6385fea8ccf54c80ec78326f78b743e
> f036773e8760a79ad9fdeea6665f86d3493d40d1
> 4c40981a5c0fe1ee5c755a55a4a8e5e3527f0bca
> 

Thanks for the info. I think I'm going to go with backporting these
changesets for now while still talking to the vendors about upgrading
their kernel. The problem is that these guys are just notoriously slow
and we have work to get done :-)


Ravi.

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Ralf Baechle [mailto:ralf@linux-mips.org] 
> Sent: Monday, March 26, 2007 10:06 AM
> To: Ravi Pratap
> Cc: David Daney; Atsushi Nemoto; miklos@szeredi.hu; 
> linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Mon, Mar 26, 2007 at 09:33:10AM -0400, Ravi Pratap wrote:
> > Yes, but isn't it a lot of work considering the lack of a 
> > flush_anon_page in 2.6.15?
> 
> David wrote about forward porting the patches in your vendor 
> kernel to a more modern kernel.  That would require some work but the
> flush_anon_page() thing would be the least of your worries.
> 
> Otherwise, you'd need to backport the about following 
> changesets into your kernel to get flush_anon_page:
> 
> 03beb07664d768db97bf454ae5c9581cd4737bb4
> df7c814ea6385fea8ccf54c80ec78326f78b743e

So I'm trying to backport these changesets and it seems that I need the
changeset that originally introduced kmap_coherent, etc. I tried some
Google searching and found this but I need your help in figuring out
which exact changesets I need.

Is it this one:

b895b66990f22a8a030c41390c538660a02bb97f

?


Thanks,

Ravi.

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Ralf Baechle [mailto:ralf@linux-mips.org] 
> Sent: Monday, March 26, 2007 10:06 AM
> To: Ravi Pratap
> Cc: David Daney; Atsushi Nemoto; miklos@szeredi.hu; 
> linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Mon, Mar 26, 2007 at 09:33:10AM -0400, Ravi Pratap wrote:
> > Yes, but isn't it a lot of work considering the lack of a 
> > flush_anon_page in 2.6.15?
> 
> David wrote about forward porting the patches in your vendor 
> kernel to a more modern kernel.  That would require some work but the
> flush_anon_page() thing would be the least of your worries.
> 
> Otherwise, you'd need to backport the about following 
> changesets into your kernel to get flush_anon_page:
> 
> 03beb07664d768db97bf454ae5c9581cd4737bb4
> df7c814ea6385fea8ccf54c80ec78326f78b743e

So I'm trying to backport these changesets and it seems that I need the
changeset that originally introduced kmap_coherent, etc. I tried some
Google searching and found this but I need your help in figuring out
which exact changesets I need.

Is it this one:

b895b66990f22a8a030c41390c538660a02bb97f

?


Thanks,

Ravi.

Re: flush_anon_page for MIPS

[Atsushi Nemoto]

On Mon, 26 Mar 2007 19:24:45 -0400, "Ravi Pratap" <Ravi.Pratap@hillcrestlabs.com> wrote:
> So I'm trying to backport these changesets and it seems that I need the
> changeset that originally introduced kmap_coherent, etc. I tried some
> Google searching and found this but I need your help in figuring out
> which exact changesets I need.
> 
> Is it this one:
> 
> b895b66990f22a8a030c41390c538660a02bb97f
> 
> ?

It was splitted into some parts when merged to mainline.

At 2.6.19 cycle:
f8829caee311207afbc882794bdc5aa0db5caf33
At 2.6.20 cycle:
bcd022801ee514e28c32837f0b3ce18c775f1a7b
9de455b20705f36384a711d4a20bcf7ba1ab180b
77fff4ae2b7bba6d66a8287d9ab948e2b6c16145

If you only needed kmap_coherent, the first one might be enough.
---
Atsushi Nemoto

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Atsushi Nemoto [mailto:anemo@mba.ocn.ne.jp] 
> Sent: Monday, March 26, 2007 11:18 PM
> To: Ravi Pratap
> Cc: ralf@linux-mips.org; ddaney@avtrex.com; 
> miklos@szeredi.hu; linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Mon, 26 Mar 2007 19:24:45 -0400, "Ravi Pratap" 
> <Ravi.Pratap@hillcrestlabs.com> wrote:
> > So I'm trying to backport these changesets and it seems that I need 
> > the changeset that originally introduced kmap_coherent, 
> etc. I tried 
> > some Google searching and found this but I need your help 
> in figuring 
> > out which exact changesets I need.
> > 
> > Is it this one:
> > 
> > b895b66990f22a8a030c41390c538660a02bb97f
> > 
> > ?
> 
> It was splitted into some parts when merged to mainline.
> 
> At 2.6.19 cycle:
> f8829caee311207afbc882794bdc5aa0db5caf33
> At 2.6.20 cycle:
> bcd022801ee514e28c32837f0b3ce18c775f1a7b
> 9de455b20705f36384a711d4a20bcf7ba1ab180b
> 77fff4ae2b7bba6d66a8287d9ab948e2b6c16145
> 
> If you only needed kmap_coherent, the first one might be enough.

Thanks - the first one, with some minor updates was good enough to apply
to 2.6.15.


Ravi.

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Atsushi Nemoto [mailto:anemo@mba.ocn.ne.jp] 
> Sent: Monday, March 26, 2007 11:18 PM
> To: Ravi Pratap
> Cc: ralf@linux-mips.org; ddaney@avtrex.com; 
> miklos@szeredi.hu; linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Mon, 26 Mar 2007 19:24:45 -0400, "Ravi Pratap" 
> <Ravi.Pratap@hillcrestlabs.com> wrote:
> > So I'm trying to backport these changesets and it seems that I need 
> > the changeset that originally introduced kmap_coherent, 
> etc. I tried 
> > some Google searching and found this but I need your help 
> in figuring 
> > out which exact changesets I need.
> > 
> > Is it this one:
> > 
> > b895b66990f22a8a030c41390c538660a02bb97f
> > 
> > ?
> 
> It was splitted into some parts when merged to mainline.
> 
> At 2.6.19 cycle:
> f8829caee311207afbc882794bdc5aa0db5caf33
> At 2.6.20 cycle:
> bcd022801ee514e28c32837f0b3ce18c775f1a7b
> 9de455b20705f36384a711d4a20bcf7ba1ab180b
> 77fff4ae2b7bba6d66a8287d9ab948e2b6c16145
> 
> If you only needed kmap_coherent, the first one might be enough.

Thanks - the first one, with some minor updates was good enough to apply
to 2.6.15.


Ravi.

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Atsushi Nemoto [mailto:anemo@mba.ocn.ne.jp] 
> Sent: Monday, March 26, 2007 11:18 PM
> To: Ravi Pratap
> Cc: ralf@linux-mips.org; ddaney@avtrex.com; 
> miklos@szeredi.hu; linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Mon, 26 Mar 2007 19:24:45 -0400, "Ravi Pratap" 
> <Ravi.Pratap@hillcrestlabs.com> wrote:
> > So I'm trying to backport these changesets and it seems that I need 
> > the changeset that originally introduced kmap_coherent, 
> etc. I tried 
> > some Google searching and found this but I need your help 
> in figuring 
> > out which exact changesets I need.
> > 
> > Is it this one:
> > 
> > b895b66990f22a8a030c41390c538660a02bb97f
> > 
> > ?
> 
> It was splitted into some parts when merged to mainline.
> 
> At 2.6.19 cycle:
> f8829caee311207afbc882794bdc5aa0db5caf33
> At 2.6.20 cycle:
> bcd022801ee514e28c32837f0b3ce18c775f1a7b
> 9de455b20705f36384a711d4a20bcf7ba1ab180b
> 77fff4ae2b7bba6d66a8287d9ab948e2b6c16145
> 
> If you only needed kmap_coherent, the first one might be enough.

I just finished backporting your patches to a 2.6.15 kernel and FUSE now
works just fine. 

Thanks a lot for all your help - you guys are an awesome bunch!

Ravi.

RE: flush_anon_page for MIPS

[Ravi Pratap]

> From: Atsushi Nemoto [mailto:anemo@mba.ocn.ne.jp] 
> Sent: Monday, March 26, 2007 11:18 PM
> To: Ravi Pratap
> Cc: ralf@linux-mips.org; ddaney@avtrex.com; 
> miklos@szeredi.hu; linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> On Mon, 26 Mar 2007 19:24:45 -0400, "Ravi Pratap" 
> <Ravi.Pratap@hillcrestlabs.com> wrote:
> > So I'm trying to backport these changesets and it seems that I need 
> > the changeset that originally introduced kmap_coherent, 
> etc. I tried 
> > some Google searching and found this but I need your help 
> in figuring 
> > out which exact changesets I need.
> > 
> > Is it this one:
> > 
> > b895b66990f22a8a030c41390c538660a02bb97f
> > 
> > ?
> 
> It was splitted into some parts when merged to mainline.
> 
> At 2.6.19 cycle:
> f8829caee311207afbc882794bdc5aa0db5caf33
> At 2.6.20 cycle:
> bcd022801ee514e28c32837f0b3ce18c775f1a7b
> 9de455b20705f36384a711d4a20bcf7ba1ab180b
> 77fff4ae2b7bba6d66a8287d9ab948e2b6c16145
> 
> If you only needed kmap_coherent, the first one might be enough.

I just finished backporting your patches to a 2.6.15 kernel and FUSE now
works just fine. 

Thanks a lot for all your help - you guys are an awesome bunch!

Ravi.

Re: flush_anon_page for MIPS

[David Daney]

Ravi Pratap wrote:
>> From: Atsushi Nemoto [mailto:anemo@mba.ocn.ne.jp] 
>> Sent: Monday, March 26, 2007 11:18 PM
>> To: Ravi Pratap
>> Cc: ralf@linux-mips.org; ddaney@avtrex.com; 
>> miklos@szeredi.hu; linux-mips@linux-mips.org
>> Subject: Re: flush_anon_page for MIPS
>>
>> On Mon, 26 Mar 2007 19:24:45 -0400, "Ravi Pratap" 
>> <Ravi.Pratap@hillcrestlabs.com> wrote:
>>> So I'm trying to backport these changesets and it seems that I need 
>>> the changeset that originally introduced kmap_coherent, 
>> etc. I tried 
>>> some Google searching and found this but I need your help 
>> in figuring 
>>> out which exact changesets I need.
>>>
>>> Is it this one:
>>>
>>> b895b66990f22a8a030c41390c538660a02bb97f
>>>
>>> ?
>> It was splitted into some parts when merged to mainline.
>>
>> At 2.6.19 cycle:
>> f8829caee311207afbc882794bdc5aa0db5caf33
>> At 2.6.20 cycle:
>> bcd022801ee514e28c32837f0b3ce18c775f1a7b
>> 9de455b20705f36384a711d4a20bcf7ba1ab180b
>> 77fff4ae2b7bba6d66a8287d9ab948e2b6c16145
>>
>> If you only needed kmap_coherent, the first one might be enough.
> 
> I just finished backporting your patches to a 2.6.15 kernel and FUSE now
> works just fine. 
> 

Would you mind posting your patch to this list?

There are some of us that are using the same processor you are that 
could find this helpful.

David Daney

RE: flush_anon_page for MIPS

[Ravi Pratap]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

> From: David Daney [mailto:ddaney@avtrex.com] 
> Sent: Wednesday, March 28, 2007 1:11 PM
> To: Ravi Pratap
> Cc: linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> > I just finished backporting your patches to a 2.6.15 kernel 
> and FUSE 
> > now works just fine.
> > 
> 
> Would you mind posting your patch to this list?

Sure, not a problem at all - it's attached.

Ravi.

[-- Attachment #2: 1003.fuse-hang.patch --]
[-- Type: application/octet-stream, Size: 14735 bytes --]

diff -r -u linux.ref/arch/mips/mm/cache.c linux.mod/arch/mips/mm/cache.c
--- linux.ref/arch/mips/mm/cache.c	2006-01-25 23:51:10.000000000 -0500
+++ linux.mod/arch/mips/mm/cache.c	2007-03-27 10:41:47.246091546 -0400
@@ -3,7 +3,8 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  *
- * Copyright (C) 1994 - 2003 by Ralf Baechle
+ * Copyright (C) 1994 - 2003, 07 by Ralf Baechle (ralf@linux-mips.org)
+ * Copyright (C) 2007 MIPS Technologies, Inc.
  */
 #include <linux/config.h>
 #include <linux/init.h>
@@ -87,6 +88,19 @@
 
 EXPORT_SYMBOL(__flush_dcache_page);
 
+void __flush_anon_page(struct page *page, unsigned long vmaddr)
+{
+	if (pages_do_alias((unsigned long)page_address(page), vmaddr)) {
+		void *kaddr;
+
+		kaddr = kmap_coherent(page, vmaddr);
+		flush_data_cache_page((unsigned long)kaddr);
+		kunmap_coherent(page);
+	}
+}
+
+EXPORT_SYMBOL(__flush_anon_page);
+
 void __update_cache(struct vm_area_struct *vma, unsigned long address,
 	pte_t pte)
 {
Only in linux.mod/arch/mips/mm: cache.c.orig
diff -r -u linux.ref/arch/mips/mm/init.c linux.mod/arch/mips/mm/init.c
--- linux.ref/arch/mips/mm/init.c	2006-01-25 23:51:10.000000000 -0500
+++ linux.mod/arch/mips/mm/init.c	2007-03-27 10:39:32.999248347 -0400
@@ -29,11 +29,34 @@
 #include <asm/cachectl.h>
 #include <asm/cpu.h>
 #include <asm/dma.h>
+#include <asm/kmap_types.h>
 #include <asm/mmu_context.h>
 #include <asm/sections.h>
 #include <asm/pgtable.h>
 #include <asm/pgalloc.h>
 #include <asm/tlb.h>
+#include <asm/fixmap.h>
+
+/* Atomicity and interruptability */
+#ifdef CONFIG_MIPS_MT_SMTC
+
+#include <asm/mipsmtregs.h>
+
+#define ENTER_CRITICAL(flags) \
+	{ \
+	unsigned int mvpflags; \
+	local_irq_save(flags);\
+	mvpflags = dvpe()
+#define EXIT_CRITICAL(flags) \
+	evpe(mvpflags); \
+	local_irq_restore(flags); \
+	}
+#else
+
+#define ENTER_CRITICAL(flags) local_irq_save(flags)
+#define EXIT_CRITICAL(flags) local_irq_restore(flags)
+
+#endif /* CONFIG_MIPS_MT_SMTC */
 
 DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);
 
@@ -78,13 +101,142 @@
 	return 1UL << order;
 }
 
-#ifdef CONFIG_HIGHMEM
-pte_t *kmap_pte;
-pgprot_t kmap_prot;
+/*
+ * These are almost like kmap_atomic / kunmap_atmic except they take an
+ * additional address argument as the hint.
+ */
 
 #define kmap_get_fixmap_pte(vaddr)					\
 	pte_offset_kernel(pmd_offset(pud_offset(pgd_offset_k(vaddr), (vaddr)), (vaddr)), (vaddr))
 
+#ifdef CONFIG_MIPS_MT_SMTC
+static pte_t *kmap_coherent_pte;
+static void __init kmap_coherent_init(void)
+{
+	unsigned long vaddr;
+
+	/* cache the first coherent kmap pte */
+	vaddr = __fix_to_virt(FIX_CMAP_BEGIN);
+	kmap_coherent_pte = kmap_get_fixmap_pte(vaddr);
+}
+#else
+static inline void kmap_coherent_init(void) {}
+#endif
+
+void *kmap_coherent(struct page *page, unsigned long addr)
+{
+	enum fixed_addresses idx;
+	unsigned long vaddr, flags, entrylo;
+	unsigned long old_ctx;
+	pte_t pte;
+	int tlbidx;
+
+	inc_preempt_count();
+	idx = (addr >> PAGE_SHIFT) & (FIX_N_COLOURS - 1);
+#ifdef CONFIG_MIPS_MT_SMTC
+	idx += FIX_N_COLOURS * smp_processor_id();
+#endif
+	vaddr = __fix_to_virt(FIX_CMAP_END - idx);
+	pte = mk_pte(page, PAGE_KERNEL);
+#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32_R1)
+	entrylo = pte.pte_high;
+#else
+	entrylo = pte_val(pte) >> 6;
+#endif
+
+	ENTER_CRITICAL(flags);
+	old_ctx = read_c0_entryhi();
+	write_c0_entryhi(vaddr & (PAGE_MASK << 1));
+	write_c0_entrylo0(entrylo);
+	write_c0_entrylo1(entrylo);
+#ifdef CONFIG_MIPS_MT_SMTC
+	set_pte(kmap_coherent_pte - (FIX_CMAP_END - idx), pte);
+	/* preload TLB instead of local_flush_tlb_one() */
+	mtc0_tlbw_hazard();
+	tlb_probe();
+	tlb_probe_hazard();
+	tlbidx = read_c0_index();
+	mtc0_tlbw_hazard();
+	if (tlbidx < 0)
+		tlb_write_random();
+	else
+		tlb_write_indexed();
+#else
+	tlbidx = read_c0_wired();
+	write_c0_wired(tlbidx + 1);
+	write_c0_index(tlbidx);
+	mtc0_tlbw_hazard();
+	tlb_write_indexed();
+#endif
+	tlbw_use_hazard();
+	write_c0_entryhi(old_ctx);
+	EXIT_CRITICAL(flags);
+
+	return (void*) vaddr;
+}
+
+#define UNIQUE_ENTRYHI(idx) (CKSEG0 + ((idx) << (PAGE_SHIFT + 1)))
+
+void kunmap_coherent(struct page *page)
+{
+#ifndef CONFIG_MIPS_MT_SMTC
+	unsigned int wired;
+	unsigned long flags, old_ctx;
+
+	ENTER_CRITICAL(flags);
+	old_ctx = read_c0_entryhi();
+	wired = read_c0_wired() - 1;
+	write_c0_wired(wired);
+	write_c0_index(wired);
+	write_c0_entryhi(UNIQUE_ENTRYHI(wired));
+	write_c0_entrylo0(0);
+	write_c0_entrylo1(0);
+	mtc0_tlbw_hazard();
+	tlb_write_indexed();
+	tlbw_use_hazard();
+	write_c0_entryhi(old_ctx);
+	EXIT_CRITICAL(flags);
+#endif
+	dec_preempt_count();
+	preempt_check_resched();
+}
+
+void copy_to_user_page(struct vm_area_struct *vma,
+	struct page *page, unsigned long vaddr, void *dst, const void *src,
+	unsigned long len)
+{
+	if (cpu_has_dc_aliases) {
+		void *vto = kmap_coherent(page, vaddr) + (vaddr & ~PAGE_MASK);
+		memcpy(vto, src, len);
+		kunmap_coherent(page);
+	} else
+		memcpy(dst, src, len);
+	if ((vma->vm_flags & VM_EXEC) && !cpu_has_ic_fills_f_dc)
+		flush_cache_page(vma, vaddr, page_to_pfn(page));
+}
+
+EXPORT_SYMBOL(copy_to_user_page);
+
+void copy_from_user_page(struct vm_area_struct *vma,
+	struct page *page, unsigned long vaddr, void *dst, const void *src,
+	unsigned long len)
+{
+	if (cpu_has_dc_aliases) {
+		void *vfrom =
+			kmap_coherent(page, vaddr) + (vaddr & ~PAGE_MASK);
+		memcpy(dst, vfrom, len);
+		kunmap_coherent(page);
+	} else
+		memcpy(dst, src, len);
+}
+
+EXPORT_SYMBOL(copy_from_user_page);
+
+
+#ifdef CONFIG_HIGHMEM
+pte_t *kmap_pte;
+pgprot_t kmap_prot;
+
 static void __init kmap_init(void)
 {
 	unsigned long kmap_vstart;
@@ -95,11 +247,12 @@
 
 	kmap_prot = PAGE_KERNEL;
 }
+#endif /* CONFIG_HIGHMEM */
 
-#ifdef CONFIG_32BIT
 void __init fixrange_init(unsigned long start, unsigned long end,
 	pgd_t *pgd_base)
 {
+#if defined(CONFIG_HIGHMEM) || defined(CONFIG_MIPS_MT_SMTC)
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
@@ -120,7 +273,7 @@
 			for (; (k < PTRS_PER_PMD) && (vaddr != end); pmd++, k++) {
 				if (pmd_none(*pmd)) {
 					pte = (pte_t *) alloc_bootmem_low_pages(PAGE_SIZE);
-					set_pmd(pmd, __pmd(pte));
+					set_pmd(pmd, __pmd((unsigned long)pte));
 					if (pte != pte_offset_kernel(pmd, 0))
 						BUG();
 				}
@@ -130,9 +283,8 @@
 		}
 		j = 0;
 	}
+#endif
 }
-#endif /* CONFIG_32BIT */
-#endif /* CONFIG_HIGHMEM */
 
 #ifndef CONFIG_NEED_MULTIPLE_NODES
 extern void pagetable_init(void);
@@ -147,6 +299,7 @@
 #ifdef CONFIG_HIGHMEM
 	kmap_init();
 #endif
+	kmap_coherent_init();
 
 	max_dma = virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT;
 	low = max_low_pfn;
Only in linux.mod/arch/mips/mm: init.c.orig
diff -r -u linux.ref/arch/mips/mm/pgtable-32.c linux.mod/arch/mips/mm/pgtable-32.c
--- linux.ref/arch/mips/mm/pgtable-32.c	2006-01-25 23:51:10.000000000 -0500
+++ linux.mod/arch/mips/mm/pgtable-32.c	2007-03-27 10:27:46.810376024 -0400
@@ -32,9 +32,10 @@
 
 void __init pagetable_init(void)
 {
-#ifdef CONFIG_HIGHMEM
 	unsigned long vaddr;
-	pgd_t *pgd, *pgd_base;
+	pgd_t *pgd_base;
+#ifdef CONFIG_HIGHMEM
+	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
 	pte_t *pte;
@@ -45,7 +46,6 @@
 	pgd_init((unsigned long)swapper_pg_dir
 		 + sizeof(pgd_t) * USER_PTRS_PER_PGD);
 
-#ifdef CONFIG_HIGHMEM
 	pgd_base = swapper_pg_dir;
 
 	/*
@@ -54,6 +54,7 @@
 	vaddr = __fix_to_virt(__end_of_fixed_addresses - 1) & PMD_MASK;
 	fixrange_init(vaddr, 0, pgd_base);
 
+#ifdef CONFIG_HIGHMEM
 	/*
 	 * Permanent kmaps:
 	 */
Only in linux.mod/arch/mips/mm: pgtable-32.c.orig
diff -r -u linux.ref/arch/mips/mm/pgtable-64.c linux.mod/arch/mips/mm/pgtable-64.c
--- linux.ref/arch/mips/mm/pgtable-64.c	2006-01-25 23:51:10.000000000 -0500
+++ linux.mod/arch/mips/mm/pgtable-64.c	2007-03-27 10:27:46.810376024 -0400
@@ -8,6 +8,7 @@
  */
 #include <linux/init.h>
 #include <linux/mm.h>
+#include <asm/fixmap.h>
 #include <asm/pgtable.h>
 
 void pgd_init(unsigned long page)
@@ -52,7 +53,17 @@
 
 void __init pagetable_init(void)
 {
+	unsigned long vaddr;
+	pgd_t *pgd_base;
+
 	/* Initialize the entire pgd.  */
 	pgd_init((unsigned long)swapper_pg_dir);
 	pmd_init((unsigned long)invalid_pmd_table, (unsigned long)invalid_pte_table);
+
+	pgd_base = swapper_pg_dir;
+	/*
+	 * Fixed mappings:
+	 */
+	vaddr = __fix_to_virt(__end_of_fixed_addresses - 1) & PMD_MASK;
+	fixrange_init(vaddr, 0, pgd_base);
 }
diff -r -u linux.ref/Documentation/cachetlb.txt linux.mod/Documentation/cachetlb.txt
--- linux.ref/Documentation/cachetlb.txt	2006-01-25 23:51:18.000000000 -0500
+++ linux.mod/Documentation/cachetlb.txt	2007-03-27 10:39:28.575023033 -0400
@@ -362,6 +362,15 @@
 	likely that you will need to flush the instruction cache
 	for copy_to_user_page().
 
+  void flush_anon_page(struct page *page, unsigned long vmaddr)
+  	When the kernel needs to access the contents of an anonymous
+	page, it calls this function (currently only
+	get_user_pages()).  Note: flush_dcache_page() deliberately
+	doesn't work for an anonymous page.  The default
+	implementation is a nop (and should remain so for all coherent
+	architectures).  For incoherent architectures, it should flush
+	the cache of the page at vmaddr in the current user process.
+
   void flush_icache_range(unsigned long start, unsigned long end)
   	When the kernel stores into addresses that it will execute
 	out of (eg when loading modules), this function is called.
Only in linux.mod/include: asm
diff -r -u linux.ref/include/asm-mips/cacheflush.h linux.mod/include/asm-mips/cacheflush.h
--- linux.ref/include/asm-mips/cacheflush.h	2006-01-25 23:51:58.000000000 -0500
+++ linux.mod/include/asm-mips/cacheflush.h	2007-03-27 18:36:24.422493144 -0400
@@ -47,6 +47,15 @@
 #define flush_dcache_mmap_lock(mapping)		do { } while (0)
 #define flush_dcache_mmap_unlock(mapping)	do { } while (0)
 
+#define ARCH_HAS_FLUSH_ANON_PAGE
+extern void __flush_anon_page(struct page *, unsigned long);
+
+static inline void flush_anon_page(struct page *page, unsigned long vmaddr)
+{
+	if (cpu_has_dc_aliases && PageAnon(page))
+		__flush_anon_page(page, vmaddr);
+}
+
 extern void (*flush_icache_page)(struct vm_area_struct *vma,
 	struct page *page);
 extern void (*flush_icache_range)(unsigned long __user start,
@@ -54,24 +63,12 @@
 #define flush_cache_vmap(start, end)		flush_cache_all()
 #define flush_cache_vunmap(start, end)		flush_cache_all()
 
-static inline void copy_to_user_page(struct vm_area_struct *vma,
-	struct page *page, unsigned long vaddr, void *dst, const void *src,
-	unsigned long len)
-{
-	if (cpu_has_dc_aliases)
-		flush_cache_page(vma, vaddr, page_to_pfn(page));
-	memcpy(dst, src, len);
-	flush_icache_page(vma, page);
-}
-
-static inline void copy_from_user_page(struct vm_area_struct *vma,
-	struct page *page, unsigned long vaddr, void *dst, const void *src,
-	unsigned long len)
-{
-	if (cpu_has_dc_aliases)
-		flush_cache_page(vma, vaddr, page_to_pfn(page));
-	memcpy(dst, src, len);
-}
+extern void copy_to_user_page(struct vm_area_struct *vma,
+    struct page *page, unsigned long vaddr, void *dst, const void *src,
+	unsigned long len);
+extern void copy_from_user_page(struct vm_area_struct *vma,
+    struct page *page, unsigned long vaddr, void *dst, const void *src,
+	unsigned long len);
 
 extern void (*flush_cache_sigtramp)(unsigned long addr);
 extern void (*flush_icache_all)(void);
@@ -93,4 +90,7 @@
 /* Run kernel code uncached, useful for cache probing functions. */
 unsigned long __init run_uncached(void *func);
 
+extern void *kmap_coherent(struct page *page, unsigned long addr);
+extern void kunmap_coherent(struct page *page);
+
 #endif /* _ASM_CACHEFLUSH_H */
Only in linux.mod/include/asm-mips: cacheflush.h~
Only in linux.mod/include/asm-mips: cacheflush.h.orig
Only in linux.mod/include/asm-mips: cacheflush.h.rej
diff -r -u linux.ref/include/asm-mips/fixmap.h linux.mod/include/asm-mips/fixmap.h
--- linux.ref/include/asm-mips/fixmap.h	2006-01-25 23:51:58.000000000 -0500
+++ linux.mod/include/asm-mips/fixmap.h	2007-03-27 10:39:07.873968964 -0400
@@ -46,8 +46,16 @@
  * fix-mapped?
  */
 enum fixed_addresses {
+#define FIX_N_COLOURS 8
+	FIX_CMAP_BEGIN,
+#ifdef CONFIG_MIPS_MT_SMTC
+	FIX_CMAP_END = FIX_CMAP_BEGIN + (FIX_N_COLOURS * NR_CPUS),
+#else
+	FIX_CMAP_END = FIX_CMAP_BEGIN + FIX_N_COLOURS,
+#endif
 #ifdef CONFIG_HIGHMEM
-	FIX_KMAP_BEGIN,	/* reserved pte's for temporary kernel mappings */
+	/* reserved pte's for temporary kernel mappings */
+	FIX_KMAP_BEGIN = FIX_CMAP_END + 1,
 	FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
 #endif
 	__end_of_fixed_addresses
@@ -70,7 +78,7 @@
  * the start of the fixmap, and leave one page empty
  * at the top of mem..
  */
-#define FIXADDR_TOP	(0xffffe000UL)
+#define FIXADDR_TOP	((unsigned long)(long)(int)0xfffe0000)
 #define FIXADDR_SIZE	(__end_of_fixed_addresses << PAGE_SHIFT)
 #define FIXADDR_START	(FIXADDR_TOP - FIXADDR_SIZE)
 
Only in linux.mod/include/asm-mips: fixmap.h~
Only in linux.mod/include/asm-mips: fixmap.h.orig
Only in linux.mod/include/asm-mips: fixmap.h.rej
diff -r -u linux.ref/include/linux/highmem.h linux.mod/include/linux/highmem.h
--- linux.ref/include/linux/highmem.h	2006-01-25 23:52:00.000000000 -0500
+++ linux.mod/include/linux/highmem.h	2007-03-27 10:39:29.043046868 -0400
@@ -7,6 +7,12 @@
 
 #include <asm/cacheflush.h>
 
+#ifndef ARCH_HAS_FLUSH_ANON_PAGE
+static inline void flush_anon_page(struct page *page, unsigned long vmaddr)
+{
+}
+#endif
+
 #ifdef CONFIG_HIGHMEM
 
 #include <asm/highmem.h>
Only in linux.mod/include/linux: version.h
diff -r -u linux.ref/mm/memory.c linux.mod/mm/memory.c
--- linux.ref/mm/memory.c	2006-01-25 23:52:04.000000000 -0500
+++ linux.mod/mm/memory.c	2007-03-27 10:39:29.363063165 -0400
@@ -1063,6 +1063,8 @@
 			}
 			if (pages) {
 				pages[i] = page;
+
+				flush_anon_page(page, start);
 				flush_dcache_page(page);
 			}
 			if (vmas)
Only in linux.mod/mm: memory.c.orig
Only in linux.mod/scripts/basic: docproc
Only in linux.mod/scripts/basic: .docproc.cmd
Only in linux.mod/scripts/basic: fixdep
Only in linux.mod/scripts/basic: .fixdep.cmd
Only in linux.mod/scripts/basic: split-include
Only in linux.mod/scripts/basic: .split-include.cmd
Only in linux.mod/scripts/kconfig: conf
Only in linux.mod/scripts/kconfig: .conf.cmd
Only in linux.mod/scripts/kconfig: conf.o
Only in linux.mod/scripts/kconfig: .conf.o.cmd
Only in linux.mod/scripts/kconfig: kxgettext.o
Only in linux.mod/scripts/kconfig: .kxgettext.o.cmd
Only in linux.mod/scripts/kconfig: lex.zconf.c
Only in linux.mod/scripts/kconfig: mconf.o
Only in linux.mod/scripts/kconfig: .mconf.o.cmd
Only in linux.mod/scripts/kconfig: zconf.hash.c
Only in linux.mod/scripts/kconfig: zconf.tab.c
Only in linux.mod/scripts/kconfig: zconf.tab.o
Only in linux.mod/scripts/kconfig: .zconf.tab.o.cmd

RE: flush_anon_page for MIPS

[Ravi Pratap]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

> From: David Daney [mailto:ddaney@avtrex.com] 
> Sent: Wednesday, March 28, 2007 1:11 PM
> To: Ravi Pratap
> Cc: linux-mips@linux-mips.org
> Subject: Re: flush_anon_page for MIPS
> 
> > I just finished backporting your patches to a 2.6.15 kernel 
> and FUSE 
> > now works just fine.
> > 
> 
> Would you mind posting your patch to this list?

Sure, not a problem at all - it's attached.

Ravi.

[-- Attachment #2: 1003.fuse-hang.patch --]
[-- Type: application/octet-stream, Size: 14735 bytes --]

diff -r -u linux.ref/arch/mips/mm/cache.c linux.mod/arch/mips/mm/cache.c
--- linux.ref/arch/mips/mm/cache.c	2006-01-25 23:51:10.000000000 -0500
+++ linux.mod/arch/mips/mm/cache.c	2007-03-27 10:41:47.246091546 -0400
@@ -3,7 +3,8 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  *
- * Copyright (C) 1994 - 2003 by Ralf Baechle
+ * Copyright (C) 1994 - 2003, 07 by Ralf Baechle (ralf@linux-mips.org)
+ * Copyright (C) 2007 MIPS Technologies, Inc.
  */
 #include <linux/config.h>
 #include <linux/init.h>
@@ -87,6 +88,19 @@
 
 EXPORT_SYMBOL(__flush_dcache_page);
 
+void __flush_anon_page(struct page *page, unsigned long vmaddr)
+{
+	if (pages_do_alias((unsigned long)page_address(page), vmaddr)) {
+		void *kaddr;
+
+		kaddr = kmap_coherent(page, vmaddr);
+		flush_data_cache_page((unsigned long)kaddr);
+		kunmap_coherent(page);
+	}
+}
+
+EXPORT_SYMBOL(__flush_anon_page);
+
 void __update_cache(struct vm_area_struct *vma, unsigned long address,
 	pte_t pte)
 {
Only in linux.mod/arch/mips/mm: cache.c.orig
diff -r -u linux.ref/arch/mips/mm/init.c linux.mod/arch/mips/mm/init.c
--- linux.ref/arch/mips/mm/init.c	2006-01-25 23:51:10.000000000 -0500
+++ linux.mod/arch/mips/mm/init.c	2007-03-27 10:39:32.999248347 -0400
@@ -29,11 +29,34 @@
 #include <asm/cachectl.h>
 #include <asm/cpu.h>
 #include <asm/dma.h>
+#include <asm/kmap_types.h>
 #include <asm/mmu_context.h>
 #include <asm/sections.h>
 #include <asm/pgtable.h>
 #include <asm/pgalloc.h>
 #include <asm/tlb.h>
+#include <asm/fixmap.h>
+
+/* Atomicity and interruptability */
+#ifdef CONFIG_MIPS_MT_SMTC
+
+#include <asm/mipsmtregs.h>
+
+#define ENTER_CRITICAL(flags) \
+	{ \
+	unsigned int mvpflags; \
+	local_irq_save(flags);\
+	mvpflags = dvpe()
+#define EXIT_CRITICAL(flags) \
+	evpe(mvpflags); \
+	local_irq_restore(flags); \
+	}
+#else
+
+#define ENTER_CRITICAL(flags) local_irq_save(flags)
+#define EXIT_CRITICAL(flags) local_irq_restore(flags)
+
+#endif /* CONFIG_MIPS_MT_SMTC */
 
 DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);
 
@@ -78,13 +101,142 @@
 	return 1UL << order;
 }
 
-#ifdef CONFIG_HIGHMEM
-pte_t *kmap_pte;
-pgprot_t kmap_prot;
+/*
+ * These are almost like kmap_atomic / kunmap_atmic except they take an
+ * additional address argument as the hint.
+ */
 
 #define kmap_get_fixmap_pte(vaddr)					\
 	pte_offset_kernel(pmd_offset(pud_offset(pgd_offset_k(vaddr), (vaddr)), (vaddr)), (vaddr))
 
+#ifdef CONFIG_MIPS_MT_SMTC
+static pte_t *kmap_coherent_pte;
+static void __init kmap_coherent_init(void)
+{
+	unsigned long vaddr;
+
+	/* cache the first coherent kmap pte */
+	vaddr = __fix_to_virt(FIX_CMAP_BEGIN);
+	kmap_coherent_pte = kmap_get_fixmap_pte(vaddr);
+}
+#else
+static inline void kmap_coherent_init(void) {}
+#endif
+
+void *kmap_coherent(struct page *page, unsigned long addr)
+{
+	enum fixed_addresses idx;
+	unsigned long vaddr, flags, entrylo;
+	unsigned long old_ctx;
+	pte_t pte;
+	int tlbidx;
+
+	inc_preempt_count();
+	idx = (addr >> PAGE_SHIFT) & (FIX_N_COLOURS - 1);
+#ifdef CONFIG_MIPS_MT_SMTC
+	idx += FIX_N_COLOURS * smp_processor_id();
+#endif
+	vaddr = __fix_to_virt(FIX_CMAP_END - idx);
+	pte = mk_pte(page, PAGE_KERNEL);
+#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32_R1)
+	entrylo = pte.pte_high;
+#else
+	entrylo = pte_val(pte) >> 6;
+#endif
+
+	ENTER_CRITICAL(flags);
+	old_ctx = read_c0_entryhi();
+	write_c0_entryhi(vaddr & (PAGE_MASK << 1));
+	write_c0_entrylo0(entrylo);
+	write_c0_entrylo1(entrylo);
+#ifdef CONFIG_MIPS_MT_SMTC
+	set_pte(kmap_coherent_pte - (FIX_CMAP_END - idx), pte);
+	/* preload TLB instead of local_flush_tlb_one() */
+	mtc0_tlbw_hazard();
+	tlb_probe();
+	tlb_probe_hazard();
+	tlbidx = read_c0_index();
+	mtc0_tlbw_hazard();
+	if (tlbidx < 0)
+		tlb_write_random();
+	else
+		tlb_write_indexed();
+#else
+	tlbidx = read_c0_wired();
+	write_c0_wired(tlbidx + 1);
+	write_c0_index(tlbidx);
+	mtc0_tlbw_hazard();
+	tlb_write_indexed();
+#endif
+	tlbw_use_hazard();
+	write_c0_entryhi(old_ctx);
+	EXIT_CRITICAL(flags);
+
+	return (void*) vaddr;
+}
+
+#define UNIQUE_ENTRYHI(idx) (CKSEG0 + ((idx) << (PAGE_SHIFT + 1)))
+
+void kunmap_coherent(struct page *page)
+{
+#ifndef CONFIG_MIPS_MT_SMTC
+	unsigned int wired;
+	unsigned long flags, old_ctx;
+
+	ENTER_CRITICAL(flags);
+	old_ctx = read_c0_entryhi();
+	wired = read_c0_wired() - 1;
+	write_c0_wired(wired);
+	write_c0_index(wired);
+	write_c0_entryhi(UNIQUE_ENTRYHI(wired));
+	write_c0_entrylo0(0);
+	write_c0_entrylo1(0);
+	mtc0_tlbw_hazard();
+	tlb_write_indexed();
+	tlbw_use_hazard();
+	write_c0_entryhi(old_ctx);
+	EXIT_CRITICAL(flags);
+#endif
+	dec_preempt_count();
+	preempt_check_resched();
+}
+
+void copy_to_user_page(struct vm_area_struct *vma,
+	struct page *page, unsigned long vaddr, void *dst, const void *src,
+	unsigned long len)
+{
+	if (cpu_has_dc_aliases) {
+		void *vto = kmap_coherent(page, vaddr) + (vaddr & ~PAGE_MASK);
+		memcpy(vto, src, len);
+		kunmap_coherent(page);
+	} else
+		memcpy(dst, src, len);
+	if ((vma->vm_flags & VM_EXEC) && !cpu_has_ic_fills_f_dc)
+		flush_cache_page(vma, vaddr, page_to_pfn(page));
+}
+
+EXPORT_SYMBOL(copy_to_user_page);
+
+void copy_from_user_page(struct vm_area_struct *vma,
+	struct page *page, unsigned long vaddr, void *dst, const void *src,
+	unsigned long len)
+{
+	if (cpu_has_dc_aliases) {
+		void *vfrom =
+			kmap_coherent(page, vaddr) + (vaddr & ~PAGE_MASK);
+		memcpy(dst, vfrom, len);
+		kunmap_coherent(page);
+	} else
+		memcpy(dst, src, len);
+}
+
+EXPORT_SYMBOL(copy_from_user_page);
+
+
+#ifdef CONFIG_HIGHMEM
+pte_t *kmap_pte;
+pgprot_t kmap_prot;
+
 static void __init kmap_init(void)
 {
 	unsigned long kmap_vstart;
@@ -95,11 +247,12 @@
 
 	kmap_prot = PAGE_KERNEL;
 }
+#endif /* CONFIG_HIGHMEM */
 
-#ifdef CONFIG_32BIT
 void __init fixrange_init(unsigned long start, unsigned long end,
 	pgd_t *pgd_base)
 {
+#if defined(CONFIG_HIGHMEM) || defined(CONFIG_MIPS_MT_SMTC)
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
@@ -120,7 +273,7 @@
 			for (; (k < PTRS_PER_PMD) && (vaddr != end); pmd++, k++) {
 				if (pmd_none(*pmd)) {
 					pte = (pte_t *) alloc_bootmem_low_pages(PAGE_SIZE);
-					set_pmd(pmd, __pmd(pte));
+					set_pmd(pmd, __pmd((unsigned long)pte));
 					if (pte != pte_offset_kernel(pmd, 0))
 						BUG();
 				}
@@ -130,9 +283,8 @@
 		}
 		j = 0;
 	}
+#endif
 }
-#endif /* CONFIG_32BIT */
-#endif /* CONFIG_HIGHMEM */
 
 #ifndef CONFIG_NEED_MULTIPLE_NODES
 extern void pagetable_init(void);
@@ -147,6 +299,7 @@
 #ifdef CONFIG_HIGHMEM
 	kmap_init();
 #endif
+	kmap_coherent_init();
 
 	max_dma = virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT;
 	low = max_low_pfn;
Only in linux.mod/arch/mips/mm: init.c.orig
diff -r -u linux.ref/arch/mips/mm/pgtable-32.c linux.mod/arch/mips/mm/pgtable-32.c
--- linux.ref/arch/mips/mm/pgtable-32.c	2006-01-25 23:51:10.000000000 -0500
+++ linux.mod/arch/mips/mm/pgtable-32.c	2007-03-27 10:27:46.810376024 -0400
@@ -32,9 +32,10 @@
 
 void __init pagetable_init(void)
 {
-#ifdef CONFIG_HIGHMEM
 	unsigned long vaddr;
-	pgd_t *pgd, *pgd_base;
+	pgd_t *pgd_base;
+#ifdef CONFIG_HIGHMEM
+	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
 	pte_t *pte;
@@ -45,7 +46,6 @@
 	pgd_init((unsigned long)swapper_pg_dir
 		 + sizeof(pgd_t) * USER_PTRS_PER_PGD);
 
-#ifdef CONFIG_HIGHMEM
 	pgd_base = swapper_pg_dir;
 
 	/*
@@ -54,6 +54,7 @@
 	vaddr = __fix_to_virt(__end_of_fixed_addresses - 1) & PMD_MASK;
 	fixrange_init(vaddr, 0, pgd_base);
 
+#ifdef CONFIG_HIGHMEM
 	/*
 	 * Permanent kmaps:
 	 */
Only in linux.mod/arch/mips/mm: pgtable-32.c.orig
diff -r -u linux.ref/arch/mips/mm/pgtable-64.c linux.mod/arch/mips/mm/pgtable-64.c
--- linux.ref/arch/mips/mm/pgtable-64.c	2006-01-25 23:51:10.000000000 -0500
+++ linux.mod/arch/mips/mm/pgtable-64.c	2007-03-27 10:27:46.810376024 -0400
@@ -8,6 +8,7 @@
  */
 #include <linux/init.h>
 #include <linux/mm.h>
+#include <asm/fixmap.h>
 #include <asm/pgtable.h>
 
 void pgd_init(unsigned long page)
@@ -52,7 +53,17 @@
 
 void __init pagetable_init(void)
 {
+	unsigned long vaddr;
+	pgd_t *pgd_base;
+
 	/* Initialize the entire pgd.  */
 	pgd_init((unsigned long)swapper_pg_dir);
 	pmd_init((unsigned long)invalid_pmd_table, (unsigned long)invalid_pte_table);
+
+	pgd_base = swapper_pg_dir;
+	/*
+	 * Fixed mappings:
+	 */
+	vaddr = __fix_to_virt(__end_of_fixed_addresses - 1) & PMD_MASK;
+	fixrange_init(vaddr, 0, pgd_base);
 }
diff -r -u linux.ref/Documentation/cachetlb.txt linux.mod/Documentation/cachetlb.txt
--- linux.ref/Documentation/cachetlb.txt	2006-01-25 23:51:18.000000000 -0500
+++ linux.mod/Documentation/cachetlb.txt	2007-03-27 10:39:28.575023033 -0400
@@ -362,6 +362,15 @@
 	likely that you will need to flush the instruction cache
 	for copy_to_user_page().
 
+  void flush_anon_page(struct page *page, unsigned long vmaddr)
+  	When the kernel needs to access the contents of an anonymous
+	page, it calls this function (currently only
+	get_user_pages()).  Note: flush_dcache_page() deliberately
+	doesn't work for an anonymous page.  The default
+	implementation is a nop (and should remain so for all coherent
+	architectures).  For incoherent architectures, it should flush
+	the cache of the page at vmaddr in the current user process.
+
   void flush_icache_range(unsigned long start, unsigned long end)
   	When the kernel stores into addresses that it will execute
 	out of (eg when loading modules), this function is called.
Only in linux.mod/include: asm
diff -r -u linux.ref/include/asm-mips/cacheflush.h linux.mod/include/asm-mips/cacheflush.h
--- linux.ref/include/asm-mips/cacheflush.h	2006-01-25 23:51:58.000000000 -0500
+++ linux.mod/include/asm-mips/cacheflush.h	2007-03-27 18:36:24.422493144 -0400
@@ -47,6 +47,15 @@
 #define flush_dcache_mmap_lock(mapping)		do { } while (0)
 #define flush_dcache_mmap_unlock(mapping)	do { } while (0)
 
+#define ARCH_HAS_FLUSH_ANON_PAGE
+extern void __flush_anon_page(struct page *, unsigned long);
+
+static inline void flush_anon_page(struct page *page, unsigned long vmaddr)
+{
+	if (cpu_has_dc_aliases && PageAnon(page))
+		__flush_anon_page(page, vmaddr);
+}
+
 extern void (*flush_icache_page)(struct vm_area_struct *vma,
 	struct page *page);
 extern void (*flush_icache_range)(unsigned long __user start,
@@ -54,24 +63,12 @@
 #define flush_cache_vmap(start, end)		flush_cache_all()
 #define flush_cache_vunmap(start, end)		flush_cache_all()
 
-static inline void copy_to_user_page(struct vm_area_struct *vma,
-	struct page *page, unsigned long vaddr, void *dst, const void *src,
-	unsigned long len)
-{
-	if (cpu_has_dc_aliases)
-		flush_cache_page(vma, vaddr, page_to_pfn(page));
-	memcpy(dst, src, len);
-	flush_icache_page(vma, page);
-}
-
-static inline void copy_from_user_page(struct vm_area_struct *vma,
-	struct page *page, unsigned long vaddr, void *dst, const void *src,
-	unsigned long len)
-{
-	if (cpu_has_dc_aliases)
-		flush_cache_page(vma, vaddr, page_to_pfn(page));
-	memcpy(dst, src, len);
-}
+extern void copy_to_user_page(struct vm_area_struct *vma,
+    struct page *page, unsigned long vaddr, void *dst, const void *src,
+	unsigned long len);
+extern void copy_from_user_page(struct vm_area_struct *vma,
+    struct page *page, unsigned long vaddr, void *dst, const void *src,
+	unsigned long len);
 
 extern void (*flush_cache_sigtramp)(unsigned long addr);
 extern void (*flush_icache_all)(void);
@@ -93,4 +90,7 @@
 /* Run kernel code uncached, useful for cache probing functions. */
 unsigned long __init run_uncached(void *func);
 
+extern void *kmap_coherent(struct page *page, unsigned long addr);
+extern void kunmap_coherent(struct page *page);
+
 #endif /* _ASM_CACHEFLUSH_H */
Only in linux.mod/include/asm-mips: cacheflush.h~
Only in linux.mod/include/asm-mips: cacheflush.h.orig
Only in linux.mod/include/asm-mips: cacheflush.h.rej
diff -r -u linux.ref/include/asm-mips/fixmap.h linux.mod/include/asm-mips/fixmap.h
--- linux.ref/include/asm-mips/fixmap.h	2006-01-25 23:51:58.000000000 -0500
+++ linux.mod/include/asm-mips/fixmap.h	2007-03-27 10:39:07.873968964 -0400
@@ -46,8 +46,16 @@
  * fix-mapped?
  */
 enum fixed_addresses {
+#define FIX_N_COLOURS 8
+	FIX_CMAP_BEGIN,
+#ifdef CONFIG_MIPS_MT_SMTC
+	FIX_CMAP_END = FIX_CMAP_BEGIN + (FIX_N_COLOURS * NR_CPUS),
+#else
+	FIX_CMAP_END = FIX_CMAP_BEGIN + FIX_N_COLOURS,
+#endif
 #ifdef CONFIG_HIGHMEM
-	FIX_KMAP_BEGIN,	/* reserved pte's for temporary kernel mappings */
+	/* reserved pte's for temporary kernel mappings */
+	FIX_KMAP_BEGIN = FIX_CMAP_END + 1,
 	FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
 #endif
 	__end_of_fixed_addresses
@@ -70,7 +78,7 @@
  * the start of the fixmap, and leave one page empty
  * at the top of mem..
  */
-#define FIXADDR_TOP	(0xffffe000UL)
+#define FIXADDR_TOP	((unsigned long)(long)(int)0xfffe0000)
 #define FIXADDR_SIZE	(__end_of_fixed_addresses << PAGE_SHIFT)
 #define FIXADDR_START	(FIXADDR_TOP - FIXADDR_SIZE)
 
Only in linux.mod/include/asm-mips: fixmap.h~
Only in linux.mod/include/asm-mips: fixmap.h.orig
Only in linux.mod/include/asm-mips: fixmap.h.rej
diff -r -u linux.ref/include/linux/highmem.h linux.mod/include/linux/highmem.h
--- linux.ref/include/linux/highmem.h	2006-01-25 23:52:00.000000000 -0500
+++ linux.mod/include/linux/highmem.h	2007-03-27 10:39:29.043046868 -0400
@@ -7,6 +7,12 @@
 
 #include <asm/cacheflush.h>
 
+#ifndef ARCH_HAS_FLUSH_ANON_PAGE
+static inline void flush_anon_page(struct page *page, unsigned long vmaddr)
+{
+}
+#endif
+
 #ifdef CONFIG_HIGHMEM
 
 #include <asm/highmem.h>
Only in linux.mod/include/linux: version.h
diff -r -u linux.ref/mm/memory.c linux.mod/mm/memory.c
--- linux.ref/mm/memory.c	2006-01-25 23:52:04.000000000 -0500
+++ linux.mod/mm/memory.c	2007-03-27 10:39:29.363063165 -0400
@@ -1063,6 +1063,8 @@
 			}
 			if (pages) {
 				pages[i] = page;
+
+				flush_anon_page(page, start);
 				flush_dcache_page(page);
 			}
 			if (vmas)
Only in linux.mod/mm: memory.c.orig
Only in linux.mod/scripts/basic: docproc
Only in linux.mod/scripts/basic: .docproc.cmd
Only in linux.mod/scripts/basic: fixdep
Only in linux.mod/scripts/basic: .fixdep.cmd
Only in linux.mod/scripts/basic: split-include
Only in linux.mod/scripts/basic: .split-include.cmd
Only in linux.mod/scripts/kconfig: conf
Only in linux.mod/scripts/kconfig: .conf.cmd
Only in linux.mod/scripts/kconfig: conf.o
Only in linux.mod/scripts/kconfig: .conf.o.cmd
Only in linux.mod/scripts/kconfig: kxgettext.o
Only in linux.mod/scripts/kconfig: .kxgettext.o.cmd
Only in linux.mod/scripts/kconfig: lex.zconf.c
Only in linux.mod/scripts/kconfig: mconf.o
Only in linux.mod/scripts/kconfig: .mconf.o.cmd
Only in linux.mod/scripts/kconfig: zconf.hash.c
Only in linux.mod/scripts/kconfig: zconf.tab.c
Only in linux.mod/scripts/kconfig: zconf.tab.o
Only in linux.mod/scripts/kconfig: .zconf.tab.o.cmd

Re: flush_anon_page for MIPS

[Ralf Baechle]

On Wed, Mar 28, 2007 at 10:10:56AM -0700, David Daney wrote:

> Would you mind posting your patch to this list?
> 
> There are some of us that are using the same processor you are that 
> could find this helpful.

You only need this patch for kernels older than last week's -2.6.16-stable.
That is linux-2.6.16-stable, linux-2.6.17-stable have it applied.

  Ralf

Re: flush_anon_page for MIPS

[David Daney]

Ralf Baechle wrote:
> On Wed, Mar 28, 2007 at 10:10:56AM -0700, David Daney wrote:
> 
>> Would you mind posting your patch to this list?
>>
>> There are some of us that are using the same processor you are that 
>> could find this helpful.
> 
> You only need this patch for kernels older than last week's -2.6.16-stable.
> That is linux-2.6.16-stable, linux-2.6.17-stable have it applied.
> 

Thanks, I know this.  It turns out that I am working with the exact 
processor/kernel that Ravi is, so his patch could be useful to me.

David Daney