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

parisc: Fix ordering of cache and TLB flushes

2018-03-11T15:21:28+00:00

commit 0adb24e03a124b79130c9499731936b11ce2677d upstream.

The change to flush_kernel_vmap_range() wasn't sufficient to avoid the
SMP stalls.  The problem is some drivers call these routines with
interrupts disabled.  Interrupts need to be enabled for flush_tlb_all()
and flush_cache_all() to work.  This version adds checks to ensure
interrupts are not disabled before calling routines that need IPI
interrupts.  When interrupts are disabled, we now drop into slower code.

The attached change fixes the ordering of cache and TLB flushes in
several cases.  When we flush the cache using the existing PTE/TLB
entries, we need to flush the TLB after doing the cache flush.  We don't
need to do this when we flush the entire instruction and data caches as
these flushes don't use the existing TLB entries.  The same is true for
tmpalias region flushes.

The flush_kernel_vmap_range() and invalidate_kernel_vmap_range()
routines have been updated.

Secondly, we added a new purge_kernel_dcache_range_asm() routine to
pacache.S and use it in invalidate_kernel_vmap_range().  Nominally,
purges are faster than flushes as the cache lines don't have to be
written back to memory.

Hopefully, this is sufficient to resolve the remaining problems due to
cache speculation.  So far, testing indicates that this is the case.  I
did work up a patch using tmpalias flushes, but there is a performance
hit because we need the physical address for each page, and we also need
to sequence access to the tmpalias flush code.  This increases the
probability of stalls.

Signed-off-by: John David Anglin 
Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

parisc: Optimize flush_kernel_vmap_range and invalidate_kernel_vmap_range

2017-03-26T11:05:57+00:00

commit 316ec0624f951166daedbe446988ef92ae72b59f upstream.

The previously submitted patch did not resolve the random segmentation
faults observed on the phantom buildd system.  There are still
unresolved problems with the Debian 4.8 and 4.9 kernels on C8000.

The attached patch removes the flush of the offset map pages and does a
whole data cache flush for large ranges.  No other arch flushes the
offset map in these routines as far as I can tell.

I have not observed any random segmentation faults on rp3440 in two
weeks of testing with 4.10.0 and 4.10.1.

Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

asm-generic: Consolidate mark_rodata_ro()

2016-02-22T07:51:37+00:00

Instead of defining mark_rodata_ro() in each architecture, consolidate it.

Signed-off-by: Kees Cook 
Acked-by: Will Deacon 
Cc: Andrew Morton 
Cc: Andy Gross 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Arnd Bergmann 
Cc: Ashok Kumar 
Cc: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Catalin Marinas 
Cc: Dan Williams 
Cc: David Brown 
Cc: David Hildenbrand 
Cc: Denys Vlasenko 
Cc: Emese Revfy 
Cc: H. Peter Anvin 
Cc: Helge Deller 
Cc: James E.J. Bottomley 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Marc Zyngier 
Cc: Mark Rutland 
Cc: Mathias Krause 
Cc: Michael Ellerman 
Cc: Nicolas Pitre 
Cc: PaX Team 
Cc: Paul Gortmaker 
Cc: Peter Zijlstra 
Cc: Ross Zwisler 
Cc: Russell King 
Cc: Rusty Russell 
Cc: Stephen Boyd 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: kernel-hardening@lists.openwall.com
Cc: linux-arch 
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-parisc@vger.kernel.org
Link: http://lkml.kernel.org/r/1455748879-21872-2-git-send-email-keescook@chromium.org
Signed-off-by: Ingo Molnar

kmap_atomic_to_page() has no users, remove it

2015-11-09T23:11:24+00:00

Removal started in commit 5bbeed12bdc3 ("sparc32: drop unused
kmap_atomic_to_page").  Let's do it across the whole tree.

Signed-off-by: Nicolas Pitre 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

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