linux-stable.git/arch, branch v3.13.5

ftrace/x86: Use breakpoints for converting function graph caller

2014-02-22T21:34:52+00:00

commit 87fbb2ac6073a7039303517546a76074feb14c84 upstream.

When the conversion was made to remove stop machine and use the breakpoint
logic instead, the modification of the function graph caller is still
done directly as though it was being done under stop machine.

As it is not converted via stop machine anymore, there is a possibility
that the code could be layed across cache lines and if another CPU is
accessing that function graph call when it is being updated, it could
cause a General Protection Fault.

Convert the update of the function graph caller to use the breakpoint
method as well.

Cc: H. Peter Anvin 
Fixes: 08d636b6d4fb "ftrace/x86: Have arch x86_64 use breakpoints instead of stop machine"
Signed-off-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman

x86, smap: smap_violation() is bogus if CONFIG_X86_SMAP is off

2014-02-22T21:34:52+00:00

commit 4640c7ee9b8953237d05a61ea3ea93981d1bc961 upstream.

If CONFIG_X86_SMAP is disabled, smap_violation() tests for conditions
which are incorrect (as the AC flag doesn't matter), causing spurious
faults.

The dynamic disabling of SMAP (nosmap on the command line) is fine
because it disables X86_FEATURE_SMAP, therefore causing the
static_cpu_has() to return false.

Found by Fengguang Wu's test system.

[ v3: move all predicates into smap_violation() ]
[ v2: use IS_ENABLED() instead of #ifdef ]

Reported-by: Fengguang Wu 
Link: http://lkml.kernel.org/r/20140213124550.GA30497@localhost
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, smap: Don't enable SMAP if CONFIG_X86_SMAP is disabled

2014-02-22T21:34:51+00:00

commit 03bbd596ac04fef47ce93a730b8f086d797c3021 upstream.

If SMAP support is not compiled into the kernel, don't enable SMAP in
CR4 -- in fact, we should clear it, because the kernel doesn't contain
the proper STAC/CLAC instructions for SMAP support.

Found by Fengguang Wu's test system.

Reported-by: Fengguang Wu 
Link: http://lkml.kernel.org/r/20140213124550.GA30497@localhost
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

ARM: pxa: fix compilation problem on AM300EPD board

2014-02-22T21:34:49+00:00

commit 29ffa48fa64fcdfc71d80593c8ae79248bc27677 upstream.

This board fails compilation like this:
arch/arm/mach-pxa/am300epd.c: In function ‘am300_cleanup’:
arch/arm/mach-pxa/am300epd.c:179:2: error: implicit declaration
of function ‘PXA_GPIO_TO_IRQ’ [-Werror=implicit-function-declaration]
  free_irq(PXA_GPIO_TO_IRQ(RDY_GPIO_PIN), par);

This was caused by commit 88f718e3fa4d67f3a8dbe79a2f97d722323e4051
"ARM: pxa: delete the custom GPIO header"

This is because it was previously getting the macro PXA_GPIO_TO_IRQ
implicitly from  which in turn implicitly included
 which in turn included .

Add the missing include so that the board compiles again.

Reported-by: Arnd Bergmann 
Signed-off-by: Linus Walleij 
Signed-off-by: Kevin Hilman 
Signed-off-by: Greg Kroah-Hartman

powerpc: Fix endian issues in kexec and crash dump code

2014-02-22T21:34:45+00:00

commit ea961a828fe7250e954f086d74d9323c3d44c3e4 upstream.

We expose a number of OF properties in the kexec and crash dump code
and these need to be big endian.

Signed-off-by: Anton Blanchard 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

s390: fix kernel crash due to linkage stack instructions

2014-02-22T21:34:44+00:00

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 
Signed-off-by: Greg Kroah-Hartman

s390/dump: Fix dump memory detection

2014-02-22T21:34:43+00:00

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 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

ARM: pxa: fix various compilation problems

2014-02-22T21:34:41+00:00

commit 9705e74671f0e4f994d86b00cecf441917c64a66 upstream.

Due to commit 88f718e3fa4d67f3a8dbe79a2f97d722323e4051
"ARM: pxa: delete the custom GPIO header" some drivers fail
compilation, for example like this:

In file included from sound/soc/pxa/spitz.c:28:0:
sound/soc/pxa/spitz.c: In function ‘spitz_ext_control’:
arch/arm/mach-pxa/include/mach/spitz.h:111:30: error:
‘PXA_NR_BUILTIN_GPIO’ undeclared (first use in this function)
 #define SPITZ_SCP_GPIO_BASE (PXA_NR_BUILTIN_GPIO)
(etc.)

This is caused by implicit inclusion of  from
various board-specific headers under  in the PXA
platform. So we take a sweep over these, and for every such
header that uses PXA_NR_BUILTIN_GPIO or PXA_GPIO_TO_IRQ()
we explicitly #include "irqs.h" so that we satisfy the
dependency in the board include file alone.

Reported-by: Arnd Bergmann 
Signed-off-by: Linus Walleij 
Signed-off-by: Kevin Hilman 
Signed-off-by: Greg Kroah-Hartman

xen: properly account for _PAGE_NUMA during xen pte translations

2014-02-22T21:34:40+00:00

commit a9c8e4beeeb64c22b84c803747487857fe424b68 upstream.

Steven Noonan forwarded a users report where they had a problem starting
vsftpd on a Xen paravirtualized guest, with this in dmesg:

  BUG: Bad page map in process vsftpd  pte:8000000493b88165 pmd:e9cc01067
  page:ffffea00124ee200 count:0 mapcount:-1 mapping:     (null) index:0x0
  page flags: 0x2ffc0000000014(referenced|dirty)
  addr:00007f97eea74000 vm_flags:00100071 anon_vma:ffff880e98f80380 mapping:          (null) index:7f97eea74
  CPU: 4 PID: 587 Comm: vsftpd Not tainted 3.12.7-1-ec2 #1
  Call Trace:
    dump_stack+0x45/0x56
    print_bad_pte+0x22e/0x250
    unmap_single_vma+0x583/0x890
    unmap_vmas+0x65/0x90
    exit_mmap+0xc5/0x170
    mmput+0x65/0x100
    do_exit+0x393/0x9e0
    do_group_exit+0xcc/0x140
    SyS_exit_group+0x14/0x20
    system_call_fastpath+0x1a/0x1f
  Disabling lock debugging due to kernel taint
  BUG: Bad rss-counter state mm:ffff880e9ca60580 idx:0 val:-1
  BUG: Bad rss-counter state mm:ffff880e9ca60580 idx:1 val:1

The issue could not be reproduced under an HVM instance with the same
kernel, so it appears to be exclusive to paravirtual Xen guests.  He
bisected the problem to commit 1667918b6483 ("mm: numa: clear numa
hinting information on mprotect") that was also included in 3.12-stable.

The problem was related to how xen translates ptes because it was not
accounting for the _PAGE_NUMA bit.  This patch splits pte_present to add
a pteval_present helper for use by xen so both bare metal and xen use
the same code when checking if a PTE is present.

[mgorman@suse.de: wrote changelog, proposed minor modifications]
[akpm@linux-foundation.org: fix typo in comment]
Reported-by: Steven Noonan 
Tested-by: Steven Noonan 
Signed-off-by: Elena Ufimtseva 
Signed-off-by: Mel Gorman 
Reviewed-by: David Vrabel 
Acked-by: Konrad Rzeszutek Wilk 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ARM: imx6: Initialize low-power mode early again

2014-02-20T19:10:11+00:00

commit e7c57ecd6019cc6392223605aed18cce257c3eff upstream.

Since commit 9e8147bb5ec5d1dda2141da70f96b98985a306cb
"ARM: imx6q: move low-power code out of clock driver"
the kernel fails to boot on i.MX6Q/D if preemption is
enabled (CONFIG_PREEMPT=y). The kernel just hangs
before the console comes up.

The above commit moved the initalization of the low-power
mode setting (enabling clocked WAIT states), which was
introduced in commit 83ae20981ae924c37d02a42c829155fc3851260c
"ARM: imx: correct low-power mode setting", from
imx6q_clks_init to imx6q_pm_init. Now it is called
much later, after all cores are enabled.

This patch moves the low-power mode initialization back
to imx6q_clks_init again (and to imx6sl_clks_init).

Signed-off-by: Philipp Zabel 
Signed-off-by: Shawn Guo 
Signed-off-by: Kevin Hilman 
Signed-off-by: Greg Kroah-Hartman