[PATCH] parisc: Ensure full cache coherency for kmap/kunmap

[PATCH] parisc: Ensure full cache coherency for kmap/kunmap

[John David Anglin]

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

Helge Deller noted a few weeks ago problems with the AIO support on  
parisc.  This change is the
result of numerous iterations on how best to deal with this problem.

The solution adopted here is to provide full cache coherency in a  
uniform manner on all parisc systems.
This involves calling flush_dcache_page() on kmap operations and  
flush_kernel_dcache_page() on
kunmap operations.  As a result, the copy_user_page() and  
clear_user_page() functions can be removed
and the overall code is simpler.

The change ensures that both userspace and kernel aliases to a mapped  
page are invalidated and flushed.
This is necessary for the correct operation of PA8800 and PA8900 based  
systems which do not support
inequivalent aliases.

With this change, I have observed no cache related issues on c8000 and  
rp3440.  It is now possible for example
to do kernel builds with "-j64" on four way systems.

On systems using XFS file systems, the patch recently posted by  
Mikulas Patocka to "fix crash using XFS
on loopback" is needed to avoid a hang caused by an uninitialized lock  
passed to flush_dcache_page()
in the page struct.

Signed-off-by: John David Anglin  <dave.anglin@bell.net>
---

[-- Attachment #2: cache-aio.d.8.txt --]
[-- Type: text/plain, Size: 3138 bytes --]

diff --git a/arch/parisc/include/asm/cacheflush.h b/arch/parisc/include/asm/cacheflush.h
index f0e2784..2f9b751 100644
--- a/arch/parisc/include/asm/cacheflush.h
+++ b/arch/parisc/include/asm/cacheflush.h
@@ -125,42 +125,38 @@ flush_anon_page(struct vm_area_struct *vma, struct page *page, unsigned long vma
 void mark_rodata_ro(void);
 #endif
 
-#ifdef CONFIG_PA8X00
-/* Only pa8800, pa8900 needs this */
-
 #include <asm/kmap_types.h>
 
 #define ARCH_HAS_KMAP
 
-void kunmap_parisc(void *addr);
-
 static inline void *kmap(struct page *page)
 {
 	might_sleep();
+	flush_dcache_page(page);
 	return page_address(page);
 }
 
 static inline void kunmap(struct page *page)
 {
-	kunmap_parisc(page_address(page));
+	flush_kernel_dcache_page_addr(page_address(page));
 }
 
 static inline void *kmap_atomic(struct page *page)
 {
 	pagefault_disable();
+	flush_dcache_page(page);
 	return page_address(page);
 }
 
 static inline void __kunmap_atomic(void *addr)
 {
-	kunmap_parisc(addr);
+	flush_kernel_dcache_page_addr(addr);
 	pagefault_enable();
 }
 
 #define kmap_atomic_prot(page, prot)	kmap_atomic(page)
 #define kmap_atomic_pfn(pfn)	kmap_atomic(pfn_to_page(pfn))
 #define kmap_atomic_to_page(ptr)	virt_to_page(ptr)
-#endif
 
 #endif /* _PARISC_CACHEFLUSH_H */
 
diff --git a/arch/parisc/include/asm/page.h b/arch/parisc/include/asm/page.h
index b7adb2a..c53fc63 100644
--- a/arch/parisc/include/asm/page.h
+++ b/arch/parisc/include/asm/page.h
@@ -28,9 +28,8 @@ struct page;
 
 void clear_page_asm(void *page);
 void copy_page_asm(void *to, void *from);
-void clear_user_page(void *vto, unsigned long vaddr, struct page *pg);
-void copy_user_page(void *vto, void *vfrom, unsigned long vaddr,
-			   struct page *pg);
+#define clear_user_page(vto, vaddr, page) clear_page_asm(vto)
+#define copy_user_page(vto, vfrom, vaddr, page) copy_page_asm(vto, vfrom)
 
 /* #define CONFIG_PARISC_TMPALIAS */
 
diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
index c035673..a725455 100644
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -388,41 +388,6 @@ void flush_kernel_dcache_page_addr(void *addr)
 }
 EXPORT_SYMBOL(flush_kernel_dcache_page_addr);
 
-void clear_user_page(void *vto, unsigned long vaddr, struct page *page)
-{
-	clear_page_asm(vto);
-	if (!parisc_requires_coherency())
-		flush_kernel_dcache_page_asm(vto);
-}
-EXPORT_SYMBOL(clear_user_page);
-
-void copy_user_page(void *vto, void *vfrom, unsigned long vaddr,
-	struct page *pg)
-{
-	/* Copy using kernel mapping.  No coherency is needed
-	   (all in kmap/kunmap) on machines that don't support
-	   non-equivalent aliasing.  However, the `from' page
-	   needs to be flushed before it can be accessed through
-	   the kernel mapping. */
-	preempt_disable();
-	flush_dcache_page_asm(__pa(vfrom), vaddr);
-	preempt_enable();
-	copy_page_asm(vto, vfrom);
-	if (!parisc_requires_coherency())
-		flush_kernel_dcache_page_asm(vto);
-}
-EXPORT_SYMBOL(copy_user_page);
-
-#ifdef CONFIG_PA8X00
-
-void kunmap_parisc(void *addr)
-{
-	if (parisc_requires_coherency())
-		flush_kernel_dcache_page_addr(addr);
-}
-EXPORT_SYMBOL(kunmap_parisc);
-#endif

Re: [PATCH] parisc: Ensure full cache coherency for kmap/kunmap

[Dave Land]

On 1/5/14 7:25 PM, John David Anglin wrote:
> Helge Deller noted a few weeks ago problems with the AIO support on
> parisc.  This change is the
> result of numerous iterations on how best to deal with this problem.
>
> The solution adopted here is to provide full cache coherency in a
> uniform manner on all parisc systems.
> This involves calling flush_dcache_page() on kmap operations and
> flush_kernel_dcache_page() on
> kunmap operations.  As a result, the copy_user_page() and
> clear_user_page() functions can be removed
> and the overall code is simpler.
>
> The change ensures that both userspace and kernel aliases to a mapped
> page are invalidated and flushed.
> This is necessary for the correct operation of PA8800 and PA8900 based
> systems which do not support
> inequivalent aliases.
>
> With this change, I have observed no cache related issues on c8000 and
> rp3440.  It is now possible for example
> to do kernel builds with "-j64" on four way systems.
>
> On systems using XFS file systems, the patch recently posted by Mikulas
> Patocka to "fix crash using XFS
> on loopback" is needed to avoid a hang caused by an uninitialized lock
> passed to flush_dcache_page()
> in the page struct.
>
> Signed-off-by: John David Anglin  <dave.anglin@bell.net>
> ---
>
>
> --
> John David Anglin    dave.anglin@bell.net
>
>

Just an FYI for all... I still get the inequivalent aliases messages 
periodically on both my PA8700 machines, and the only tasks they're 
doing at the moment is buildd work, and a LAMP-based website on the 
'hpviz' (J6750), though I haven't seen any of those messages pointing 
toward issues with PHP, Apache2, or MySQL... at least not yet. Hopefully 
this patch will help eliminate the problem on the PA8700 series and 
others. ;-)

Dave L.

-- 
Dave Land
Land Computer Service  xmechanic@landcomp.net
ICQ: 676030523

Re: [PATCH] parisc: Ensure full cache coherency for kmap/kunmap

[Helge Deller]

On 01/06/2014 07:25 AM, Dave Land wrote:
> On 1/5/14 7:25 PM, John David Anglin wrote:
>> Helge Deller noted a few weeks ago problems with the AIO support
>> on parisc.  This change is the result of numerous iterations on how
>> best to deal with this problem.
>> 
>> The solution adopted here is to provide full cache coherency in a 
>> uniform manner on all parisc systems. This involves calling
>> flush_dcache_page() on kmap operations and 
>> flush_kernel_dcache_page() on kunmap operations.  As a result, the
>> copy_user_page() and clear_user_page() functions can be removed and
>> the overall code is simpler.
>> 
>> The change ensures that both userspace and kernel aliases to a
>> mapped page are invalidated and flushed. This is necessary for the
>> correct operation of PA8800 and PA8900 based systems which do not
>> support inequivalent aliases.
>> 
>> With this change, I have observed no cache related issues on c8000
>> and rp3440.  It is now possible for example to do kernel builds
>> with "-j64" on four way systems.
>> 
>> On systems using XFS file systems, the patch recently posted by
>> Mikulas Patocka to "fix crash using XFS on loopback" is needed to
>> avoid a hang caused by an uninitialized lock passed to
>> flush_dcache_page() in the page struct.
>> 
>> Signed-off-by: John David Anglin  <dave.anglin@bell.net> ---
>> 
>> 
> 
> Just an FYI for all... I still get the inequivalent aliases messages
> periodically on both my PA8700 machines, and the only tasks they're

Just for the record:

The inequivalent aliases messages are uncritical and they are not related to this
patch. Those messages just mean, that the userspace processes needs to
be rebuilt to correctly align their data areas. A rebuild of those will
fix this problem.

The patch above should fix kernel bugs like this one:

[154422.816000] IASQ: 0000000000000000 0000000000000000 IAOQ: 000000004021fa9c 000000004021faa0
[154422.964000]  IIR: 03ffe01f    ISR: 0000000010340000  IOR: 000006ffdb36c7f0
[154422.964000]  CPU:        1   CR30: 00000001fff6c000 CR31: ffffffffffffffff
[154423.108000]  ORIG_R28: 00000001ef520c48
[154423.108000]  IAOQ[0]: iov_iter_advance+0x3c/0xd0
[154423.252000]  IAOQ[1]: iov_iter_advance+0x40/0xd0
[154423.252000]  RP(r2): generic_file_buffered_write+0x20c/0x3e8
[154423.400000] Backtrace:
[154423.400000]  [<000000004022198c>] generic_file_buffered_write+0x20c/0x3e8
[154423.544000]  [<00000000402242b4>] __generic_file_aio_write+0x24c/0x470
[154423.544000]  [<0000000040224570>] generic_file_aio_write+0x98/0x128
[154423.692000]  [<00000000107ab51c>] ext4_file_write+0xc4/0x558 [ext4]
[154423.836000]  [<000000004029ec78>] do_sync_write+0x90/0xe8
[154423.836000]  [<000000004029f6ac>] vfs_write+0xdc/0x298
[154423.984000]  [<00000000402a05c0>] SyS_write+0xa0/0x108
[154423.984000]  [<0000000040105fc0>] syscall_exit+0x0/0x14

> doing at the moment is buildd work, and a LAMP-based website on the
> 'hpviz' (J6750), though I haven't seen any of those messages pointing
> toward issues with PHP, Apache2, or MySQL... at least not yet.
> Hopefully this patch will help eliminate the problem on the PA8700
> series and others. ;-)

Helge