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

arm64: mark reserved memblock regions explicitly in iomem

2017-01-06T10:16:25+00:00

commit e7cd190385d17790cc3eb3821b1094b00aacf325 upstream.

Kdump(kexec-tools) parses /proc/iomem to identify all the memory regions
on the system. Since the current kernel names "nomap" regions, like UEFI
runtime services code/data, as "System RAM," kexec-tools sets up elf core
header to include them in a crash dump file (/proc/vmcore).

Then crash dump kernel parses UEFI memory map again, re-marks those regions
as "nomap" and does not create a memory mapping for them unlike the other
areas of System RAM. In this case, copying /proc/vmcore through
copy_oldmem_page() on crash dump kernel will end up with a kernel abort,
as reported in [1].

This patch names all the "nomap" regions explicitly as "reserved" so that
we can exclude them from a crash dump file. acpi_os_ioremap() must also
be modified because those regions have WB attributes [2].

Apart from kdump, this change also matches x86's use of acpi (and
/proc/iomem).

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/448186.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/450089.html

Reviewed-by: Catalin Marinas 
Tested-by: James Morse 
Reviewed-by: James Morse 
Signed-off-by: AKASHI Takahiro 
Signed-off-by: Will Deacon 
Cc: Matthias Brugger 
Signed-off-by: Greg Kroah-Hartman

arm/xen: Use alloc_percpu rather than __alloc_percpu

2017-01-06T10:16:25+00:00

commit 24d5373dda7c00a438d26016bce140299fae675e upstream.

The function xen_guest_init is using __alloc_percpu with an alignment
which are not power of two.

However, the percpu allocator never supported alignments which are not power
of two and has always behaved incorectly in thise case.

Commit 3ca45a4 "percpu: ensure requested alignment is power of two"
introduced a check which trigger a warning [1] when booting linux-next
on Xen. But in reality this bug was always present.

This can be fixed by replacing the call to __alloc_percpu with
alloc_percpu. The latter will use an alignment which are a power of two.

[1]

[    0.023921] illegal size (48) or align (48) for percpu allocation
[    0.024167] ------------[ cut here ]------------
[    0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 pcpu_alloc+0x88/0x6c0
[    0.024584] Modules linked in:
[    0.024708]
[    0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.9.0-rc7-next-20161128 #473
[    0.025012] Hardware name: Foundation-v8A (DT)
[    0.025162] task: ffff80003d870000 task.stack: ffff80003d844000
[    0.025351] PC is at pcpu_alloc+0x88/0x6c0
[    0.025490] LR is at pcpu_alloc+0x88/0x6c0
[    0.025624] pc : [] lr : []
pstate: 60000045
[    0.025830] sp : ffff80003d847cd0
[    0.025946] x29: ffff80003d847cd0 x28: 0000000000000000
[    0.026147] x27: 0000000000000000 x26: 0000000000000000
[    0.026348] x25: 0000000000000000 x24: 0000000000000000
[    0.026549] x23: 0000000000000000 x22: 00000000024000c0
[    0.026752] x21: ffff000008e97000 x20: 0000000000000000
[    0.026953] x19: 0000000000000030 x18: 0000000000000010
[    0.027155] x17: 0000000000000a3f x16: 00000000deadbeef
[    0.027357] x15: 0000000000000006 x14: ffff000088f79c3f
[    0.027573] x13: ffff000008f79c4d x12: 0000000000000041
[    0.027782] x11: 0000000000000006 x10: 0000000000000042
[    0.027995] x9 : ffff80003d847a40 x8 : 6f697461636f6c6c
[    0.028208] x7 : 6120757063726570 x6 : ffff000008f79c84
[    0.028419] x5 : 0000000000000005 x4 : 0000000000000000
[    0.028628] x3 : 0000000000000000 x2 : 000000000000017f
[    0.028840] x1 : ffff80003d870000 x0 : 0000000000000035
[    0.029056]
[    0.029152] ---[ end trace 0000000000000000 ]---
[    0.029297] Call trace:
[    0.029403] Exception stack(0xffff80003d847b00 to
                               0xffff80003d847c30)
[    0.029621] 7b00: 0000000000000030 0001000000000000
ffff80003d847cd0 ffff00000818e678
[    0.029901] 7b20: 0000000000000002 0000000000000004
ffff000008f7c060 0000000000000035
[    0.030153] 7b40: ffff000008f79000 ffff000008c4cd88
ffff80003d847bf0 ffff000008101778
[    0.030402] 7b60: 0000000000000030 0000000000000000
ffff000008e97000 00000000024000c0
[    0.030647] 7b80: 0000000000000000 0000000000000000
0000000000000000 0000000000000000
[    0.030895] 7ba0: 0000000000000035 ffff80003d870000
000000000000017f 0000000000000000
[    0.031144] 7bc0: 0000000000000000 0000000000000005
ffff000008f79c84 6120757063726570
[    0.031394] 7be0: 6f697461636f6c6c ffff80003d847a40
0000000000000042 0000000000000006
[    0.031643] 7c00: 0000000000000041 ffff000008f79c4d
ffff000088f79c3f 0000000000000006
[    0.031877] 7c20: 00000000deadbeef 0000000000000a3f
[    0.032051] [] pcpu_alloc+0x88/0x6c0
[    0.032229] [] __alloc_percpu+0x18/0x20
[    0.032409] [] xen_guest_init+0x174/0x2f4
[    0.032591] [] do_one_initcall+0x38/0x130
[    0.032783] [] kernel_init_freeable+0xe0/0x248
[    0.032995] [] kernel_init+0x10/0x100
[    0.033172] [] ret_from_fork+0x10/0x50

Reported-by: Wei Chen 
Link: https://lkml.org/lkml/2016/11/28/669
Signed-off-by: Julien Grall 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Greg Kroah-Hartman

m68k: Fix ndelay() macro

2016-12-15T16:50:36+00:00

commit 7e251bb21ae08ca2e4fb28cc0981fac2685a8efa upstream.

The current ndelay() macro definition has an extra semi-colon at the
end of the line thus leading to a compilation error when ndelay is used
in a conditional block without curly braces like this one:

	if (cond)
		ndelay(t);
	else
		...

which, after the preprocessor pass gives:

	if (cond)
		m68k_ndelay(t);;
	else
		...

thus leading to the following gcc error:

	error: 'else' without a previous 'if'

Remove this extra semi-colon.

Signed-off-by: Boris Brezillon 
Fixes: c8ee038bd1488 ("m68k: Implement ndelay() based on the existing udelay() logic")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: imx7d: fix LCDIF clock assignment

2016-12-15T16:50:36+00:00

commit 4b707fa00a80b19b80bc8df6f1cbf4bdd9c91402 upstream.

The eLCDIF IP of the i.MX 7 SoC knows multiple clocks and lists them
separately:

Clock      Clock Root              Description
apb_clk    MAIN_AXI_CLK_ROOT       AXI clock
pix_clk    LCDIF_PIXEL_CLK_ROOT    Pixel clock
ipg_clk_s  MAIN_AXI_CLK_ROOT       Peripheral access clock

All of them are switched by a single gate, which is part of the
IMX7D_LCDIF_PIXEL_ROOT_CLK clock. Hence using that clock also for
the AXI bus clock (clock-name "axi") makes sure the gate gets
enabled when accessing registers.

There seem to be no separate AXI display clock, and the clock is
optional. Hence remove the dummy clock.

This fixes kernel freezes when starting the X-Server (which
disables/re-enables the display controller).

Fixes: e8ed73f691bd ("ARM: dts: imx7d: add lcdif support")
Signed-off-by: Stefan Agner 
Reviewed-by: Fabio Estevam 
Acked-by: Shawn Guo 
Signed-off-by: Olof Johansson 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: orion5x: fix number of sata port for linkstation ls-gl

2016-12-15T16:50:36+00:00

commit 038ccb3e8cee52e07dc118ff99f47eaebc1d0746 upstream.

Bug report from Debian [0] shows there's minor changed model of
Linkstation LS-GL that uses the 2nd SATA port of the SoC.
So it's necessary to enable two SATA ports, though for that specific
model only the 2nd one is used.

[0] https://bugs.debian.org/845611

Fixes: b1742ffa9ddb ("ARM: dts: orion5x: add device tree for buffalo linkstation ls-gl")
Reported-by: Ryan Tandy 
Tested-by: Ryan Tandy 
Signed-off-by: Roger Shimizu 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Greg Kroah-Hartman

perf/x86: Fix full width counter, counter overflow

2016-12-15T16:50:35+00:00

commit 7f612a7f0bc13a2361a152862435b7941156b6af upstream.

Lukasz reported that perf stat counters overflow handling is broken on KNL/SLM.

Both these parts have full_width_write set, and that does indeed have
a problem. In order to deal with counter wrap, we must sample the
counter at at least half the counter period (see also the sampling
theorem) such that we can unambiguously reconstruct the count.

However commit:

  069e0c3c4058 ("perf/x86/intel: Support full width counting")

sets the sampling interval to the full period, not half.

Fixing that exposes another issue, in that we must not sign extend the
delta value when we shift it right; the counter cannot have
decremented after all.

With both these issues fixed, counter overflow functions correctly
again.

Reported-by: Lukasz Odzioba 
Tested-by: Liang, Kan 
Tested-by: Odzioba, Lukasz 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Fixes: 069e0c3c4058 ("perf/x86/intel: Support full width counting")
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

parisc: Fix TLB related boot crash on SMP machines

2016-12-15T16:50:34+00:00

commit 24d0492b7d5d321a9c5846c8c974eba9823ffaa0 upstream.

At bootup we run measurements to calculate the best threshold for when we
should be using full TLB flushes instead of just flushing a specific amount of
TLB entries.  This performance test is run over the kernel text segment.

But running this TLB performance test on the kernel text segment turned out to
crash some SMP machines when the kernel text pages were mapped as huge pages.

To avoid those crashes this patch simply skips this test on some SMP machines
and calculates an optimal threshold based on the maximum number of available
TLB entries and number of online CPUs.

On a technical side, this seems to happen:
The TLB measurement code uses flush_tlb_kernel_range() to flush specific TLB
entries with a page size of 4k (pdtlb 0(sr1,addr)). On UP systems this purge
instruction seems to work without problems even if the pages were mapped as
huge pages.  But on SMP systems the TLB purge instruction is broadcasted to
other CPUs. Those CPUs then crash the machine because the page size is not as
expected.  C8000 machines with PA8800/PA8900 CPUs were not affected by this
problem, because the required cache coherency prohibits to use huge pages at
all.  Sadly I didn't found any documentation about this behaviour, so this
finding is purely based on testing with phyiscal SMP machines (A500-44 and
J5000, both were 2-way boxes).

Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

parisc: Remove unnecessary TLB purges from flush_dcache_page_asm and flush_icache_page_asm

2016-12-15T16:50:34+00:00

commit febe42964fe182281859b3d43d844bb25ca49367 upstream.

We have four routines in pacache.S that use temporary alias pages:
copy_user_page_asm(), clear_user_page_asm(), flush_dcache_page_asm() and
flush_icache_page_asm().  copy_user_page_asm() and clear_user_page_asm()
don't purge the TLB entry used for the operation.
flush_dcache_page_asm() and flush_icache_page_asm do purge the entry.

Presumably, this was thought to optimize TLB use.  However, the
operation is quite heavy weight on PA 1.X processors as we need to take
the TLB lock and a TLB broadcast is sent to all processors.

This patch removes the purges from flush_dcache_page_asm() and
flush_icache_page_asm.

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

parisc: Purge TLB before setting PTE

2016-12-15T16:50:34+00:00

commit c78e710c1c9fbeff43dddc0aa3d0ff458e70b0cc upstream.

The attached change interchanges the order of purging the TLB and
setting the corresponding page table entry.  TLB purges are strongly
ordered.  It occurred to me one night that setting the PTE first might
have subtle ordering issues on SMP machines and cause random memory
corruption.

A TLB lock guards the insertion of user TLB entries.  So after the TLB
is purged, a new entry can't be inserted until the lock is released.
This ensures that the new PTE value is used when the lock is released.

Since making this change, no random segmentation faults have been
observed on the Debian hppa buildd servers.

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

powerpc/boot: Fix build failure in 32-bit boot wrapper

2016-12-15T16:50:34+00:00

commit 10c77dba40ff58fc03587b3b60725bb7fd723183 upstream.

OPAL is not callable from 32-bit mode and the assembly code for it
may not even build (depending on how binutils was configured).

References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpcspe&ver=4.8.7-1&stamp=1479203712
Fixes: 656ad58ef19e ("powerpc/boot: Add OPAL console to epapr wrappers")
Signed-off-by: Ben Hutchings 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman