Messages in this thread | | | From | John David Anglin <> | Subject | Re: [PATCH] aio: fix D-cache aliasing issues | Date | Sun, 17 Nov 2013 20:15:14 -0500 |
| |
On 17-Nov-13, at 7:52 PM, James Bottomley wrote:
>> +void flush_user_dcache_page(struct page *page); >> + > > The split into flush_kernel.. and flush_user.. is pointless. We > have no > use for a flush_user_.. API because it's not part of the standard > linux > one. Plus it's going to confuse those who come after us no end > because > now we're different from every other architecture.
I introduced it because it seemed to be what was needed on parisc when we map a kernel page on PA8800/PA8900. We need this to ensure what the kernel sees is up to date and also to ensure that we don't create inequivalent aliases between the user and kernel mappings.
> >> #define flush_kernel_dcache_range(start,size) \ >> flush_kernel_dcache_range_asm((start), (start)+(size)); >> /* vmap range flushes and invalidates. Architecturally, we don't >> need >> @@ -125,18 +127,27 @@ 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_parisc(struct page *page) >> +{ >> + if (parisc_requires_coherency()) >> + flush_user_dcache_page(page); >> +} > > No ... if we're genuinely moving coherency into kmap/kunmap, this > has to > become > > flush_dcache_page(page); > > unconditionally.
There are two things about flush_dcache_page(page):
1) The flush could be deferred. I don't think we want that. 2) It seems to unnecessarily call flush_kernel_dcache_page().
Dave -- John David Anglin dave.anglin@bell.net
| |