linux-stable.git/arch/parisc/include/asm/cacheflush.h, branch linux-4.3.y

sched/preempt, mm/kmap: Explicitly disable/enable preemption in kmap_atomic_*

2015-05-19T06:39:14+00:00

The existing code relies on pagefault_disable() implicitly disabling
preemption, so that no schedule will happen between kmap_atomic() and
kunmap_atomic().

Let's make this explicit, to prepare for pagefault_disable() not
touching preemption anymore.

Reviewed-and-tested-by: Thomas Gleixner 
Signed-off-by: David Hildenbrand 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: David.Laight@ACULAB.COM
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: airlied@linux.ie
Cc: akpm@linux-foundation.org
Cc: benh@kernel.crashing.org
Cc: bigeasy@linutronix.de
Cc: borntraeger@de.ibm.com
Cc: daniel.vetter@intel.com
Cc: heiko.carstens@de.ibm.com
Cc: herbert@gondor.apana.org.au
Cc: hocko@suse.cz
Cc: hughd@google.com
Cc: mst@redhat.com
Cc: paulus@samba.org
Cc: ralf@linux-mips.org
Cc: schwidefsky@de.ibm.com
Cc: yang.shi@windriver.com
Link: http://lkml.kernel.org/r/1431359540-32227-5-git-send-email-dahi@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar

parisc: fix cache-flushing

2014-02-02T19:57:16+00:00

This commit:
f8dae00684d678afa13041ef170cecfd1297ed40: parisc: Ensure full cache coherency for kmap/kunmap
caused negative caching side-effects, e.g. hanging processes with expect and
too many inequivalent alias messages from flush_dcache_page() on Debian 5 systems.

This patch now partly reverts it and has been in production use on our debian buildd
makeservers since a week without any major problems.

Signed-off-by: Helge Deller 
Signed-off-by: John David Anglin 
Cc: stable@vger.kernel.org # v3.9+
Signed-off-by: Helge Deller

parisc: Ensure full cache coherency for kmap/kunmap

2014-01-08T22:02:57+00:00

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 
Cc: stable@vger.kernel.org # v3.9+
Signed-off-by: Helge Deller

parisc: Change kunmap macro to static inline function

2013-04-25T20:36:31+00:00

Change kunmap macro to static inline function to fix build error
compiling drivers/base/dma-buf.c.

Without the change, the following error can occur:

   CC      drivers/base/dma-buf.o
drivers/base/dma-buf.c: In function 'dma_buf_kunmap':
drivers/base/dma-buf.c:427:46:
error: macro "kunmap" passed 3 arguments, but takes just 1

I believe parisc is the only arch to implement kunmap using a macro.

Signed-off-by: John David Anglin 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Signed-off-by: Helge Deller

parisc: disable preemption while flushing D- or I-caches through TMPALIAS region

2013-02-20T21:50:38+00:00

It is necessary to disable preemption during cache flushes done through the
TMPALIAS region to ensure that the TLB setup is not clobbered by another flush.

Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller

highmem: kill all __kmap_atomic()

2012-03-20T13:48:30+00:00

[swarren@nvidia.com: highmem: Fix ARM build break due to __kmap_atomic rename]

Signed-off-by: Stephen Warren 
Signed-off-by: Cong Wang

[PARISC] prevent speculative re-read on cache flush

2011-04-15T17:55:56+00:00

According to Appendix F, the TLB is the primary arbiter of speculation.
Thus, if a page has a TLB entry, it may be speculatively read into the
cache.  On linux, this can cause us incoherencies because if we're about
to do a disk read, we call get_user_pages() to do the flush/invalidate
in user space, but we still potentially have the user TLB entries, and
the cache could speculate the lines back into userspace (thus causing
stale data to be used).  This is fixed by purging the TLB entries before
we flush through the tmpalias space.  Now, the only way the line could
be re-speculated is if the user actually tries to touch it (which is not
allowed).

Signed-off-by: James Bottomley

Merge branch 'fixes' into for-next

2011-02-10T17:20:53+00:00

[PARISC] fix vmap flush/invalidate

2011-02-09T17:22:21+00:00

On parisc, we never implemented invalidate_kernel_vmap_range() because
it was unnecessary for the xfs use case.  However, we do need to
implement an invalidate for the opposite use case (which occurred in a
recent NFS change) where the user wants to read through the vmap range
and write via the kernel address.  There's an additional complexity to
this in that if the page has no userspace mappings, it might have dirty
cache lines in the kernel (indicated by the PG_dcache_dirty bit).  In
order to get full coherency, we need to flush these pages through the
kernel mapping before invalidating the vmap range.

Signed-off-by: James Bottomley

parisc: flush pages through tmpalias space

2011-01-15T14:44:40+00:00

The kernel has an 8M tmpailas space (originally designed for copying
and clearing pages but now only used for clearing).  The idea is
to place zeros into the cache above a physical page rather than into
the physical page and flush the cache, because often the zeros end up
being replaced quickly anyway.

We can also use the tmpalias space for flushing a page.  The difference
here is that we have to do tmpalias processing in the non access data and
instruction traps.  The principle is the same: as long as we know the physical
address and have a virtual address congruent to the real one, the flush will
be effective.

In order to use the tmpalias space, the icache miss path has to be enhanced to
check for the alias region to make the fic instruction effective.

Signed-off-by: James Bottomley