linux-stable.git/arch, branch v4.9.54

s390/mm: make pmdp_invalidate() do invalidation only

2017-10-08T08:26:12+00:00

commit 91c575b335766effa6103eba42a82aea560c365f upstream.

Commit 227be799c39a ("s390/mm: uninline pmdp_xxx functions from pgtable.h")
inadvertently changed the behavior of pmdp_invalidate(), so that it now
clears the pmd instead of just marking it as invalid. Fix this by restoring
the original behavior.

A possible impact of the misbehaving pmdp_invalidate() would be the
MADV_DONTNEED races (see commits ced10803 and 58ceeb6b), although we
should not have any negative impact on the related dirty/young flags,
since those flags are not set by the hardware on s390.

Fixes: 227be799c39a ("s390/mm: uninline pmdp_xxx functions from pgtable.h")
Signed-off-by: Gerald Schaefer 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

ARM: remove duplicate 'const' annotations'

2017-10-08T08:26:11+00:00

commit 0527873b29b077fc8e656acd63e1866b429fef55 upstream.

gcc-7 warns about some declarations that are more 'const' than necessary:

arch/arm/mach-at91/pm.c:338:34: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
 static const struct of_device_id const ramc_ids[] __initconst = {
arch/arm/mach-bcm/bcm_kona_smc.c:36:34: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
 static const struct of_device_id const bcm_kona_smc_ids[] __initconst = {
arch/arm/mach-spear/time.c:207:34: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
 static const struct of_device_id const timer_of_match[] __initconst = {
arch/arm/mach-omap2/prm_common.c:714:34: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
 static const struct of_device_id const omap_prcm_dt_match_table[] __initconst = {
arch/arm/mach-omap2/vc.c:562:35: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
 static const struct i2c_init_data const omap4_i2c_timing_data[] __initconst = {

The ones in arch/arm were apparently all introduced accidentally by one
commit that correctly marked a lot of variables as __initconst.

Fixes: 19c233b79d1a ("ARM: appropriate __init annotation for const data")
Acked-by: Alexandre Belloni 
Acked-by: Tony Lindgren 
Acked-by: Nicolas Pitre 
Acked-by: Florian Fainelli 
Acked-by: Viresh Kumar 
Acked-by: Krzysztof Hałasa 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: BCM5301X: Fix memory start address

2017-10-08T08:26:11+00:00

[ Upstream commit 88d1fa70c21d7b431386cfe70cdc514d98b0c9c4 ]

Memory starts at 0x80000000, not 0.  0 "works" due to mirrior of the
first 128M of RAM to that address.  Anything greater than 128M will
quickly find nothing there.  Correcting the starting address has
everything working again.

Signed-off-by: Jon Mason 
Fixes: 7eb05f6d ("ARM: dts: bcm5301x: Add BCM SVK DT files")
Signed-off-by: Florian Fainelli 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

x86/acpi: Restore the order of CPU IDs

2017-10-08T08:26:10+00:00

[ Upstream commit 2b85b3d22920db7473e5fed5719e7955c0ec323e ]

The following commits:

  f7c28833c2 ("x86/acpi: Enable acpi to register all possible cpus at
boot time") and 8f54969dc8 ("x86/acpi: Introduce persistent storage
for cpuid <-> apicid mapping")

... registered all the possible CPUs at boot time via ACPI tables to
make the mapping of cpuid <-> apicid fixed. Both enabled and disabled
CPUs could have a logical CPU ID after boot time.

But, ACPI tables are unreliable. the number amd order of Local APIC
entries which depends on the firmware is often inconsistent with the
physical devices. Even if they are consistent, The disabled CPUs which
take up some logical CPU IDs will also make the order discontinuous.

Revert the part of disabled CPUs registration, keep the allocation
logic of logical CPU IDs and also keep some code location changes.

Signed-off-by: Dou Liyang 
Tested-by: Xiaolong Ye 
Cc: rjw@rjwysocki.net
Cc: linux-acpi@vger.kernel.org
Cc: guzheng1@huawei.com
Cc: izumi.taku@jp.fujitsu.com
Cc: lenb@kernel.org
Link: http://lkml.kernel.org/r/1488528147-2279-4-git-send-email-douly.fnst@cn.fujitsu.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

parisc: perf: Fix potential NULL pointer dereference

2017-10-08T08:26:10+00:00

[ Upstream commit 74e3f6e63da6c8e8246fba1689e040bc926b4a1a ]

Fix potential NULL pointer dereference and clean up
coding style errors (code indent, trailing whitespaces).

Signed-off-by: Arvind Yadav 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

MIPS: smp-cps: Fix retrieval of VPE mask on big endian CPUs

2017-10-08T08:26:09+00:00

[ Upstream commit fb2155e3c30dc2043b52020e26965067a3e7779c ]

The vpe_mask member of struct core_boot_config is of type atomic_t,
which is a 32bit type. In cps-vec.S this member was being retrieved by a
PTR_L macro, which on 64bit systems is a 64bit load. On little endian
systems this is OK, since the double word that is retrieved will have
the required less significant word in the correct position. However, on
big endian systems the less significant word of the load is retrieved
from address+4, and the more significant from address+0. The destination
register therefore ends up with the required word in the more
significant word
e.g. when starting the second VP of a big endian 64bit system, the load

PTR_L    ta2, COREBOOTCFG_VPEMASK(a0)

ends up setting register ta2 to 0x0000000300000000

When this value is written to the CPC it is ignored, since it is
invalid to write anything larger than 4 bits. This results in any VP
other than VP0 in a core failing to start in 64bit big endian systems.

Change the load to a 32bit load word instruction to fix the bug.

Fixes: f12401d7219f ("MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes")
Signed-off-by: Matt Redfearn 
Cc: Paul Burton 
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15787/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

MIPS: IRQ Stack: Unwind IRQ stack onto task stack

2017-10-08T08:26:09+00:00

[ Upstream commit db8466c581cca1a08b505f1319c3ecd246f16fa8 ]

When the separate IRQ stack was introduced, stack unwinding only
proceeded as far as the top of the IRQ stack, leading to kernel
backtraces being less useful, lacking the trace of what was interrupted.

Fix this by providing a means for the kernel to unwind the IRQ stack
onto the interrupted task stack. The processor state is saved to the
kernel task stack on interrupt. The IRQ_STACK_START macro reserves an
unsigned long at the top of the IRQ stack where the interrupted task
stack pointer can be saved. After the active stack is switched to the
IRQ stack, save the interrupted tasks stack pointer to the reserved
location.

Fix the stack unwinding code to look for the frame being the top of the
IRQ stack and if so get the next frame from the saved location. The
existing test does not work with the separate stack since the ra is no
longer pointed at ret_from_{irq,exception}.

The test to stop unwinding the stack 32 bytes from the top of a stack
must be modified to allow unwinding to continue up to the location of
the saved task stack pointer when on the IRQ stack. The low / high marks
of the stack are set depending on whether the sp is on an irq stack or
not.

Signed-off-by: Matt Redfearn 
Cc: Paolo Bonzini 
Cc: Marcin Nowakowski 
Cc: Masanari Iida 
Cc: Chris Metcalf 
Cc: James Hogan 
Cc: Paul Burton 
Cc: Ingo Molnar 
Cc: Jason A. Donenfeld 
Cc: Andrew Morton 
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15788/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

kasan: do not sanitize kexec purgatory

2017-10-08T08:26:09+00:00

[ Upstream commit 13a6798e4a03096b11bf402a063786a7be55d426 ]

Fixes this:

  kexec: Undefined symbol: __asan_load8_noabort
  kexec-bzImage64: Loading purgatory failed

Link: http://lkml.kernel.org/r/1489672155.4458.7.camel@gmx.de
Signed-off-by: Mike Galbraith 
Cc: Alexander Potapenko 
Cc: Andrey Ryabinin 
Cc: Dmitry Vyukov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mips: ath79: clock:- Unmap region obtained by of_iomap

2017-10-08T08:26:07+00:00

[ Upstream commit b3d91db3f71d5f70ea60d900425a3f96aeb3d065 ]

Free memory mapping, if ath79_clocks_init_dt_ng is not successful.

Signed-off-by: Arvind Yadav 
Fixes: 3bdf1071ba7d ("MIPS: ath79: update devicetree clock support for AR9132")
Cc: antonynpavlov@gmail.com
Cc: albeu@free.fr
Cc: hackpascal@gmail.com
Cc: sboyd@codeaurora.org
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/14915/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

MIPS: Lantiq: Fix another request_mem_region() return code check

2017-10-08T08:26:07+00:00

[ Upstream commit 98ea51cb0c8ce009d9da1fd7b48f0ff1d7a9bbb0 ]

Hauke already fixed a couple of them, but one instance remains
that checks for a negative integer when it should check
for a NULL pointer:

arch/mips/lantiq/xway/sysctrl.c: In function 'ltq_soc_init':
arch/mips/lantiq/xway/sysctrl.c:473:19: error: ordered comparison of pointer with integer zero [-Werror=extra]

Fixes: 6e807852676a ("MIPS: Lantiq: Fix check for return value of request_mem_region()")
Signed-off-by: Arnd Bergmann 
Cc: John Crispin 
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15043/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman