3.4-stable patches

added patches:
	s390-dump-fix-dump-memory-detection.patch
	s390-fix-kernel-crash-due-to-linkage-stack-instructions.patch

diff --git a/queue-3.4/s390-dump-fix-dump-memory-detection.patch b/queue-3.4/s390-dump-fix-dump-memory-detection.patch
new file mode 100644 (file)
index 0000000..9d36d6c
--- /dev/null
+++ b/queue-3.4/s390-dump-fix-dump-memory-detection.patch
@@ -0,0 +1,62 @@
+From d7736ff5be31edaa4fe5ab62810c64529a24b149 Mon Sep 17 00:00:00 2001
+From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
+Date: Thu, 30 Jan 2014 16:14:02 +0100
+Subject: s390/dump: Fix dump memory detection
+
+From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
+
+commit d7736ff5be31edaa4fe5ab62810c64529a24b149 upstream.
+
+Dumps created by kdump or zfcpdump can contain invalid memory holes when
+dumping z/VM systems that have memory pressure.
+
+For example:
+
+   # zgetdump -i /proc/vmcore.
+   Memory map:
+   0000000000000000 - 0000000000bfffff (12 MB)
+   0000000000e00000 - 00000000014fffff (7 MB)
+   000000000bd00000 - 00000000f3bfffff (3711 MB)
+
+The memory detection function find_memory_chunks() issues tprot to
+find valid memory chunks. In case of CMM it can happen that pages are
+marked as unstable via set_page_unstable() in arch_free_page().
+If z/VM has released that pages, tprot returns -EFAULT and indicates
+a memory hole.
+
+So fix this and switch off CMM in case of kdump or zfcpdump.
+
+Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/mm/page-states.c |   10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/arch/s390/mm/page-states.c
++++ b/arch/s390/mm/page-states.c
+@@ -12,6 +12,8 @@
+ #include <linux/mm.h>
+ #include <linux/gfp.h>
+ #include <linux/init.h>
++#include <asm/setup.h>
++#include <asm/ipl.h>
+ 
+ #define ESSA_SET_STABLE               1
+ #define ESSA_SET_UNUSED               2
+@@ -41,6 +43,14 @@ void __init cmma_init(void)
+ 
+       if (!cmma_flag)
+               return;
++      /*
++       * Disable CMM for dump, otherwise  the tprot based memory
++       * detection can fail because of unstable pages.
++       */
++      if (OLDMEM_BASE || ipl_info.type == IPL_TYPE_FCP_DUMP) {
++              cmma_flag = 0;
++              return;
++      }
+       asm volatile(
+               "       .insn rrf,0xb9ab0000,%1,%1,0,0\n"
+               "0:     la      %0,0\n"

diff --git a/queue-3.4/s390-fix-kernel-crash-due-to-linkage-stack-instructions.patch b/queue-3.4/s390-fix-kernel-crash-due-to-linkage-stack-instructions.patch
new file mode 100644 (file)
index 0000000..d462cdf
--- /dev/null
+++ b/queue-3.4/s390-fix-kernel-crash-due-to-linkage-stack-instructions.patch
@@ -0,0 +1,55 @@
+From 8d7f6690cedb83456edd41c9bd583783f0703bf0 Mon Sep 17 00:00:00 2001
+From: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Date: Mon, 3 Feb 2014 17:37:15 +0100
+Subject: s390: fix kernel crash due to linkage stack instructions
+
+From: Martin Schwidefsky <schwidefsky@de.ibm.com>
+
+commit 8d7f6690cedb83456edd41c9bd583783f0703bf0 upstream.
+
+The kernel currently crashes with a low-address-protection exception
+if a user space process executes an instruction that tries to use the
+linkage stack. Set the base-ASTE origin and the subspace-ASTE origin
+of the dispatchable-unit-control-table to point to a dummy ASTE.
+Set up control register 15 to point to an empty linkage stack with no
+room left.
+
+A user space process with a linkage stack instruction will still crash
+but with a different exception which is correctly translated to a
+segmentation fault instead of a kernel oops.
+
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/kernel/head64.S |    7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/arch/s390/kernel/head64.S
++++ b/arch/s390/kernel/head64.S
+@@ -61,7 +61,7 @@ ENTRY(startup_continue)
+       .quad   0                       # cr12: tracing off
+       .quad   0                       # cr13: home space segment table
+       .quad   0xc0000000              # cr14: machine check handling off
+-      .quad   0                       # cr15: linkage stack operations
++      .quad   .Llinkage_stack         # cr15: linkage stack operations
+ .Lpcmsk:.quad 0x0000000180000000
+ .L4malign:.quad 0xffffffffffc00000
+ .Lscan2g:.quad        0x80000000 + 0x20000 - 8        # 2GB + 128K - 8
+@@ -69,12 +69,15 @@ ENTRY(startup_continue)
+ .Lparmaddr:
+       .quad   PARMAREA
+       .align  64
+-.Lduct: .long 0,0,0,0,.Lduald,0,0,0
++.Lduct: .long 0,.Laste,.Laste,0,.Lduald,0,0,0
+       .long   0,0,0,0,0,0,0,0
++.Laste:       .quad   0,0xffffffffffffffff,0,0,0,0,0,0
+       .align  128
+ .Lduald:.rept 8
+       .long   0x80000000,0,0,0        # invalid access-list entries
+       .endr
++.Llinkage_stack:
++      .long   0,0,0x89000000,0,0,0,0x8a000000,0
+ 
+ ENTRY(_ehead)
+ 

diff --git a/queue-3.4/series b/queue-3.4/series
index 55657cfed7f823692b499a20db8c2e6f7c94f895..d16a60f77f1b5fe3f77ad9815c7552650bdb9765 100644 (file)
--- a/queue-3.4/series
+++ b/queue-3.4/series
@@ -1,3 +1,5 @@
 xen-blkfront-handle-backend-closed-without-closing.patch
 fs-file.c-fdtable-avoid-triggering-ooms-from-alloc_fdmem.patch
 mac80211-fix-fragmentation-code-particularly-for-encryption.patch
+s390-dump-fix-dump-memory-detection.patch
+s390-fix-kernel-crash-due-to-linkage-stack-instructions.patch