kernel/arch/powerpc, branch linux-3.2.y

powerpc/pseries: Add empty update_numa_cpu_lookup_table() for NUMA=n

2018-05-31T23:30:16Z

commit c1e150ceb61e4a585bad156da15c33bfe89f5858 upstream. When CONFIG_NUMA is not set, the build fails with: arch/powerpc/platforms/pseries/hotplug-cpu.c:335:4: error: déclaration implicite de la fonction « update_numa_cpu_lookup_table » So we have to add update_numa_cpu_lookup_table() as an empty function when CONFIG_NUMA is not set. Fixes: 1d9a090783be ("powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove") Signed-off-by: Corentin Labbe Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings

powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove

2018-05-31T23:30:13Z

commit 1d9a090783bef19fe8cdec878620d22f05191316 upstream. When DLPAR removing a CPU, the unmapping of the cpu from a node in unmap_cpu_from_node() should also invalidate the CPUs entry in the numa_cpu_lookup_table. There is not a guarantee that on a subsequent DLPAR add of the CPU the associativity will be the same and thus could be in a different node. Invalidating the entry in the numa_cpu_lookup_table causes the associativity to be read from the device tree at the time of the add. The current behavior of not invalidating the CPUs entry in the numa_cpu_lookup_table can result in scenarios where the the topology layout of CPUs in the partition does not match the device tree or the topology reported by the HMC. This bug looks like it was introduced in 2004 in the commit titled "ppc64: cpu hotplug notifier for numa", which is 6b15e4e87e32 in the linux-fullhist tree. Hence tag it for all stable releases. Signed-off-by: Nathan Fontenot Reviewed-by: Tyrel Datwyler Signed-off-by: Michael Ellerman [bwh: Backported to 3.2: - update_numa_cpu_lookup_table() wasn't defined anywhere before - Adjust context] Signed-off-by: Ben Hutchings

powerpc: Correct instruction code for xxlor instruction

2017-11-26T13:51:06Z

commit 93b2d3cf3733b4060d3623161551f51ea1ab5499 upstream. The instruction code for xxlor that commit 0016a4cf5582 ("powerpc: Emulate most Book I instructions in emulate_step()", 2010-06-15) added is actually the code for xxlnor. It is used in get_vsr() and put_vsr() and the effect of the error is that if emulate_step is used to emulate a VSX load or store from any register other than vsr0, the bitwise complement of the correct value will be loaded or stored. This corrects the error. Fixes: 0016a4cf5582 ("powerpc: Emulate most Book I instructions in emulate_step()") Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

powerpc/44x: Fix mask and shift to zero bug

2017-11-26T13:51:06Z

commit 8d046759f6ad75824fdf7b9c9a3da0272ea9ea92 upstream. My static checker complains that 0x00001800 >> 13 is zero. Looking at the context, it seems like a copy and paste bug from the line below and probably 0x3 << 13 or 0x00006000 was intended. Fixes: 2af59f7d5c3e ("[POWERPC] 4xx: Add 405GPr and 405EP support in boot wrapper") Signed-off-by: Dan Carpenter Acked-by: Benjamin Herrenschmidt Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings

powerpc/mm: Fix check of multiple 16G pages from device tree

2017-11-26T13:51:01Z

commit 23493c121912a39f0262e0dbeb236e1d39efa4d5 upstream. The offset of hugepage block will not be 16G, if the expected page is more than one. Calculate the totol size instead of the hardcode value. Fixes: 4792adbac9eb ("powerpc: Don't use a 16G page if beyond mem= limits") Signed-off-by: Rui Teng Tested-by: Anshuman Khandual Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings

powerpc: Fix emulation of mfocrf in emulate_step()

2017-10-12T14:27:16Z

commit 64e756c55aa46fc18fd53e8f3598b73b528d8637 upstream. From POWER4 onwards, mfocrf() only places the specified CR field into the destination GPR, and the rest of it is set to 0. The PowerPC AS from version 3.0 now requires this behaviour. The emulation code currently puts the entire CR into the destination GPR. Fix it. Fixes: 6888199f7fe5 ("[POWERPC] Emulate more instructions in software") Signed-off-by: Anton Blanchard Acked-by: Naveen N. Rao Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings

powerpc/asm: Mark cr0 as clobbered in mftb()

2017-10-12T14:27:16Z

commit 2400fd822f467cb4c886c879d8ad99feac9cf319 upstream. The workaround for the CELL timebase bug does not correctly mark cr0 as being clobbered. This means GCC doesn't know that the asm block changes cr0 and might leave the result of an unrelated comparison in cr0 across the block, which we then trash, leading to basically random behaviour. Fixes: 859deea949c3 ("[POWERPC] Cell timebase bug workaround") Signed-off-by: Oliver O'Halloran [mpe: Tweak change log and flag for stable] Signed-off-by: Michael Ellerman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

powerpc/64: Initialise thread_info for emergency stacks

2017-09-15T17:30:55Z

commit 34f19ff1b5a0d11e46df479623d6936460105c9f upstream. Emergency stacks have their thread_info mostly uninitialised, which in particular means garbage preempt_count values. Emergency stack code runs with interrupts disabled entirely, and is used very rarely, so this has been unnoticed so far. It was found by a proposed new powerpc watchdog that takes a soft-NMI directly from the masked_interrupt handler and using the emergency stack. That crashed at BUG_ON(in_nmi()) in nmi_enter(). preempt_count()s were found to be garbage. To fix this, zero the entire THREAD_SIZE allocation, and initialize the thread_info. Reported-by: Abdul Haleem Signed-off-by: Nicholas Piggin [mpe: Move it all into setup_64.c, use a function not a macro. Fix crashes on Cell by setting preempt_count to 0 not HARDIRQ_OFFSET] Signed-off-by: Michael Ellerman [bwh: Backported to 3.2: - There's only one emergency stack - No need to call klp_init_thread_info() - Add the ti variable in emergency_stack_init()] Signed-off-by: Ben Hutchings

powerpc/kprobes: Pause function_graph tracing during jprobes handling

2017-09-15T17:30:54Z

commit a9f8553e935f26cb5447f67e280946b0923cd2dc upstream. This fixes a crash when function_graph and jprobes are used together. This is essentially commit 237d28db036e ("ftrace/jprobes/x86: Fix conflict between jprobes and function graph tracing"), but for powerpc. Jprobes breaks function_graph tracing since the jprobe hook needs to use jprobe_return(), which never returns back to the hook, but instead to the original jprobe'd function. The solution is to momentarily pause function_graph tracing before invoking the jprobe hook and re-enable it when returning back to the original jprobe'd function. Fixes: 6794c78243bf ("powerpc64: port of the function graph tracer") Signed-off-by: Naveen N. Rao Acked-by: Masami Hiramatsu Acked-by: Steven Rostedt (VMware) Signed-off-by: Michael Ellerman [bwh: Backported to 3.2: include , which apparently gets included indirectly upstream] Signed-off-by: Ben Hutchings

powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash

2017-09-15T17:30:45Z

commit e41e53cd4fe331d0d1f06f8e4ed7e2cc63ee2c34 upstream. virt_addr_valid() is supposed to tell you if it's OK to call virt_to_page() on an address. What this means in practice is that it should only return true for addresses in the linear mapping which are backed by a valid PFN. We are failing to properly check that the address is in the linear mapping, because virt_to_pfn() will return a valid looking PFN for more or less any address. That bug is actually caused by __pa(), used in virt_to_pfn(). eg: __pa(0xc000000000010000) = 0x10000 # Good __pa(0xd000000000010000) = 0x10000 # Bad! __pa(0x0000000000010000) = 0x10000 # Bad! This started happening after commit bdbc29c19b26 ("powerpc: Work around gcc miscompilation of __pa() on 64-bit") (Aug 2013), where we changed the definition of __pa() to work around a GCC bug. Prior to that we subtracted PAGE_OFFSET from the value passed to __pa(), meaning __pa() of a 0xd or 0x0 address would give you something bogus back. Until we can verify if that GCC bug is no longer an issue, or come up with another solution, this commit does the minimal fix to make virt_addr_valid() work, by explicitly checking that the address is in the linear mapping region. Fixes: bdbc29c19b26 ("powerpc: Work around gcc miscompilation of __pa() on 64-bit") Signed-off-by: Michael Ellerman Reviewed-by: Paul Mackerras Reviewed-by: Balbir Singh Tested-by: Breno Leitao [bwh: Backported to 3.2: open-code virt_to_pfn()] Signed-off-by: Ben Hutchings