- 11 May, 2018 2 commits
-
-
Michael Ellerman authored
The code patching code has always been a bit confused about whether it's best to use void *, unsigned int *, char *, etc. to point to instructions. In fact in the feature fixups tests we use both unsigned int[] and u8[] in different places. Unfortunately the tests that use unsigned int[] calculate the size of the code blocks using subtraction of those unsigned int pointers, and then pass the result to memcmp(). This means we're only comparing 1/4 of the bytes we need to, because we need to multiply by sizeof(unsigned int) to get the number of *bytes*. The result is that the tests do all the patching and then only compare some of the resulting code, so patching bugs that only effect that last 3/4 of the code could slip through undetected. It turns out that hasn't been happening, although one test had a bad expected case (see previous commit). Fix it for now by multiplying the size by 4 in the affected functions. Fixes: 362e7701 ("powerpc: Add self-tests of the feature fixup code") Epic-brown-paper-bag-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Michael Ellerman authored
The expected case for this test was wrong, the source of the alternate code sequence is: FTR_SECTION_ELSE 2: or 2,2,2 PPC_LCMPI r3,1 beq 3f blt 2b b 3f b 1b ALT_FTR_SECTION_END(0, 1) 3: or 1,1,1 or 2,2,2 4: or 3,3,3 So when it's patched the '3' label should still be on the 'or 1,1,1', and the 4 label is irrelevant and can be removed. Fixes: 362e7701 ("powerpc: Add self-tests of the feature fixup code") Signed-off-by:
-
- 10 May, 2018 21 commits
-
-
Michael Ellerman authored
If the systbl_chk.sh checks fail we print a message, but with no indication that it's an error. That makes it hard to find in build logs with eg. grep. So prefix any output with "Error:". Signed-off-by: -
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Al Viro authored
it had always been pointless - compat_sys_select() sign-extends the first argument just fine on its own. Signed-off-by:
-
Michael Ellerman authored
Currently the select system call is wired up with the SYSX_SPU() macro. The SYSX_SPU() is not handled by systbl_chk.c, which means the syscall number for select is not checked. That hides the fact that the syscall number for select is actually __NR__newselect not __NR_select. In a following patch we'd like to drop ppc32_select() which means select will become a regular COMPAT_SYS_SPU() syscall. But COMPAT_SYS_SPU() can't deal with the fact that the syscall number is actually __NR__newselect. We also can't just redefine __NR_select because that's still used for the old select call. So add a new COMPAT_NEW_SPU() that does the same thing as COMPAT_SYS_SPU() except it encodes that we're using the new number. Signed-off-by: -
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Torsten Duwe authored
The "Power Architecture 64-Bit ELF V2 ABI" says in section 2.3.2.3: [...] There are several rules that must be adhered to in order to ensure reliable and consistent call chain backtracing: * Before a function calls any other function, it shall establish its own stack frame, whose size shall be a multiple of 16 bytes. – In instances where a function’s prologue creates a stack frame, the back-chain word of the stack frame shall be updated atomically with the value of the stack pointer (r1) when a back chain is implemented. (This must be supported as default by all ELF V2 ABI-compliant environments.) [...] – The function shall save the link register that contains its return address in the LR save doubleword of its caller’s stack frame before calling another function. To me this sounds like the equivalent of HAVE_RELIABLE_STACKTRACE. This patch may be unneccessarily limited to ppc64le, but OTOH the only user of this flag so far is livepatching, which is only implemented on PPCs with 64-LE, a.k.a. ELF ABI v2. Feel free to add other ppc variants, but so far only ppc64le got tested. This change also implements save_stack_trace_tsk_reliable() for ppc64le that checks for the above conditions, where possible. Signed-off-by:
Torsten Duwe <duwe@suse.de> Signed-off-by:
Nicolai Stange <nstange@suse.de> Acked-by:
Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
-
Nicholas Piggin authored
Provide timebase and timebase of last heartbeat in watchdog lockup messages. Also provide a stack trace of when a CPU becomes un-stuck, which can be useful -- it could be where irqs are re-enabled, so it may be the end of the critical section which is responsible for the latency which is useful information. Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
-
Nicholas Piggin authored
The watchdog heartbeat timestamp is updated when the local heartbeat timer fires (or touch_nmi_watchdog() is called). This is an interesting data point, so don't overwrite it when the soft-NMI interrupt detects a hard lockup. That code came from a pre- merge version to prevent hard lockup messages flood, but that's taken care of with the stuck CPU logic now, so there is no reason to update the heartbeat timestamp here. Signed-off-by:
-
Cédric Le Goater authored
This is not the case for the moment, but future releases of pHyp might need to introduce some synchronisation routines under the hood which would make the XIVE hcalls longer to complete. As this was done for H_INT_RESET, let's wrap the other hcalls in a loop catching the H_LONG_BUSY_* codes. Signed-off-by:
Cédric Le Goater <clg@kaod.org> Signed-off-by:
-
Cédric Le Goater authored
The hcall H_INT_RESET should be called to make sure XIVE is fully reseted. Signed-off-by:
-
Cédric Le Goater authored
The hcall H_INT_RESET can take some time to complete and in such cases it returns H_LONG_BUSY_* codes requiring the machine to sleep for a while before retrying. Signed-off-by:
-
Cédric Le Goater authored
The kexec_state KEXEC_STATE_IRQS_OFF barrier is reached by all secondary CPUs before the kexec_cpu_down() operation is called on secondaries. This can raise conflicts and provoque errors in the XIVE hcalls when XIVE is shutdown with H_INT_RESET on the primary CPU. To synchronize the kexec_cpu_down() operations and make sure the secondaries have completed their task before the primary starts doing the same, let's move the primary kexec_cpu_down() after the KEXEC_STATE_REAL_MODE barrier. This change of the ending sequence of kexec is mostly useful on the pseries platform but it impacts also the powernv, ps3 and 85xx platforms. powernv can be easily tested and fixed but some caution is required for the other two. Signed-off-by:
-
Nicholas Piggin authored
For consideration: * Add NVDIMM support - Enables greater testing, mambo device. * Add IPv6 support built in + additional modules - Because it's 2018 maan. * Add DEFERRED_STRUCT_PAGE_INIT - Let's see what breaks. * Add PPC_MEMTRACE - Small powernv debugfs driver for getting hardware traces. * Add MEMORY_FAILURE - Machine check exceptions can now drive memory failure. * Turn on FANOTIFY - This is the current filesystem notification feature. * Turn on SCOM_DEBUGFS - Handy for hardware/firmware debugging, security risk? * Turn on async SCSI scanning - Let's see what breaks. * Add MLX5 driver as a module - Popular demand. * Add CRYPTO_CRCT10DIF_VPMSUM - POWER8 T10DIF acceleration. * Make a bunch of USB hid drivers modules. * Make SCSI SG, SR, and FC modules - FC is huge. * Make video drivers except AST GPU modules - Also huge. * Make PCI serial driver a module - Uncommon. * Make more things modules, NFS FS, RAM disk, netconsole, MS-DOS fs. * Get rid of /dev/port - Not used. * Remove PPS and PTP subsystms - Unusual. * Remove legacy BSD ttys - Long dead. * Remove IDE - Deprecated and replaced with ATA. * Remove WIRELESS - Until we get POWER9 laptops. * Remove RAW - Long deprecated in favour of direct IO. * Remove floppy, parport, and PS2 input devices - not supported. * Remove virtio drivers, ballooning - We're host only. * Remove PPP - Sorry Paulus. This results in a significantly smaller vmlinux: text data bss dec filename 13143383 5277944 1317856 19739183 vanilla 12263281 4852074 1341720 18457075 patched Signed-off-by: -
Jonathan Neuschäfer authored
The B43 driver only needs CONFIG_SSB to support the WLAN card found in the Wii. Configure it accordingly, and disable BCMA bus support to save a bit of space. Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
-
Jonathan Neuschäfer authored
This allows access to the SD card and the BCM4318 Wifi module. Signed-off-by:
-
Jonathan Neuschäfer authored
Now that there's a GPIO driver for the Wii, let's enable the following drivers: - the GPIO driver itself - gpio-keys - gpio-poweroff - gpio-leds and a few LED triggers Signed-off-by:
-
Jonathan Neuschäfer authored
The Wii doesn't have built-in Ethernet and USB Ethernet adapters are in a different menu. Disable CONFIG_ETHERNET to save some space in support code for Ethernet drivers. Note that this patch doesn't disable any Ethernet drivers, because they are not enabled by default. Signed-off-by:
-
Wolfram Sang authored
Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
Michael Ellerman authored
The hcall_exit() tracepoint has retval defined as unsigned long. That leads to humours results like: bash-3686 [009] d..2 854.134094: hcall_entry: opcode=24 bash-3686 [009] d..2 854.134095: hcall_exit: opcode=24 retval=18446744073709551609 It's normal for some hcalls to return negative values, displaying them as unsigned isn't very helpful. So change it to signed. bash-3711 [001] d..2 471.691008: hcall_entry: opcode=24 bash-3711 [001] d..2 471.691008: hcall_exit: opcode=24 retval=-7 Which can be more easily compared to H_NOT_FOUND in hvcall.h Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Ravi Bangoria <ravi.bangoria@linux.ibm.com>
-
- 07 May, 2018 4 commits
-
-
Balbir Singh authored
This commit was a stop-gap to prevent crashes on hotunplug, caused by the mismatch between the 1G mappings used for the linear mapping and the memory block size. Those issues are now resolved because we split the linear mapping at hotunplug time if necessary, as implemented in commit 4dd5f8a9 ("powerpc/mm/radix: Split linear mapping on hot-unplug"). Signed-off-by:
Balbir Singh <bsingharora@gmail.com> Signed-off-by:
Michael Neuling <mikey@neuling.org> Tested-by:
Rashmica Gupta <rashmica.g@gmail.com> Tested-by:
-
Christophe Leroy authored
By using IS_ENABLED() we can simplify __set_pte_at() by removing redundant *ptep = pte. Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Reviewed-by:
-
Christophe Leroy authored
_PAGE_BUSY is always 0, remove it. Signed-off-by:
-
Christophe Leroy authored
When nohash and book3s header were split, some hash related stuff remained in the nohash header. This patch removes them. Signed-off-by:
-
- 03 May, 2018 13 commits
-
-
Mahesh Salgaonkar authored
Unregister fadump on kexec down path otherwise the fadump registration in new kexec-ed kernel complains that fadump is already registered. This makes new kernel to continue using fadump registered by previous kernel which may lead to invalid vmcore generation. Hence this patch fixes this issue by un-registering fadump in fadump_cleanup() which is called during kexec path so that new kernel can register fadump with new valid values. Fixes: b500afff ("fadump: Invalidate registration and release reserved memory for general use.") Cc: stable@vger.kernel.org # v3.4+ Signed-off-by:
Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by:
-
Hari Bathini authored
FADump capture kernel boots in restricted memory environment preserving the context of previous kernel to save vmcore. Supporting hugepages in such environment makes things unnecessarily complicated, as hugepages need memory set aside for them. This means most of the capture kernel's memory is used in supporting hugepages. In most cases, this results in out-of-memory issues while booting FADump capture kernel. But hugepages are not of much use in capture kernel whose only job is to save vmcore. So, disabling hugepages support, when fadump is active, is a reliable solution for the out of memory issues. Introducing a flag variable to disable HugeTLB support when fadump is active. Signed-off-by:
Hari Bathini <hbathini@linux.vnet.ibm.com> Reviewed-by:
-
Mahesh Salgaonkar authored
The second kernel, during early boot after the crash, reserves rest of the memory above boot memory size to make sure it does not touch any of the dump memory area. It uses memblock_reserve() that reserves the specified memory region irrespective of memory holes present within that region. There are chances where previous kernel would have hot removed some of its memory leaving memory holes behind. In such cases fadump kernel reports incorrect number of reserved pages through arch_reserved_kernel_pages() hook causing kernel to hang or panic. Fix this by excluding memory holes while reserving rest of the memory above boot memory size during second kernel boot after crash. Signed-off-by:
-
Michael Ellerman authored
config TRACING_SUPPORT has an exception for PPC32, because PPC32 didn't have irqflags tracing support. But that hasn't been true since commit 5d38902c ("powerpc: Add irqtrace support for 32-bit powerpc") (Jun 2009). So remove the exception for PPC32 and the comment. Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Paul Gortmaker authored
I no longer have a functional version of this board for even the most basic sanity boot testing, and they have not been available for purchase for quite some years now. There is no point in adding a burden to testing coverage that does walk all the possible defconfigs, so with all the above in mind, it makes sense to remove it. Of course it will remain in the git history for anyone who happens to stumble on one and wants to tinker with it. Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Michael Ellerman authored
We've had dynamic ftrace support for over 9 years since Steve first wrote it, all the distros use dynamic, and static is basically untested these days, so drop support for static ftrace. Signed-off-by:
-
Naveen N. Rao authored
With -mprofile-kernel, we always save the full register state in ftrace_caller(). While this works, this is inefficient if we're not interested in the register state, such as when we're using the function tracer. Rename the existing ftrace_caller() as ftrace_regs_caller() and provide a simpler implementation for ftrace_caller() that is used when registers are not required to be saved. Signed-off-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by:
-
Naveen N. Rao authored
Our implementation matches that of the generic version, which also handles FTRACE_UPDATE_MODIFY_CALL. So, remove our implementation in favor of the generic version. Signed-off-by:
-
Naveen N. Rao authored
For R_PPC64_REL24 relocations, we suppress emitting instructions for TOC load/restore in the relocation stub if the relocation is for _mcount() call when using -mprofile-kernel ABI. To detect this, we check if the preceding instructions are per the standard set of instructions emitted by gcc: either the two instruction sequence of 'mflr r0; std r0,16(r1)', or the more optimized variant of a single 'mflr r0'. This is not sufficient since nothing prevents users from hand coding sequences involving a 'mflr r0' followed by a 'bl'. For removing the toc save instruction from the stub, we additionally check if the symbol is "_mcount". Add the same check here as well. Also rename is_early_mcount_callsite() to is_mprofile_mcount_callsite() since that is what is being checked. The use of "early" is misleading since there is nothing involving this function that qualifies as early. Fixes: 15308664 ("powerpc/ftrace: Add support for -mprofile-kernel ftrace ABI") Signed-off-by:
-
Naveen N. Rao authored
If function_graph tracer is enabled during kexec, we see the below exception in the simulator: root@(none):/# kexec -e kvm: exiting hardware virtualization kexec_core: Starting new kernel [ 19.262020070,5] OPAL: Switch to big-endian OS kexec: Starting switchover sequence. Interrupt to 0xC000000000004380 from 0xC000000000004380 ** Execution stopped: Continuous Interrupt, Instruction caused exception, ** Now that we have a more effective way to completely disable ftrace on ppc64, let's also use that before switching to a new kernel during kexec. Signed-off-by:
-
Naveen N. Rao authored
During guest entry/exit, we switch over to/from the guest MMU context and we cannot take exceptions in the hypervisor code. Since ftrace may be enabled and since it can result in us taking a trap, disable ftrace by setting paca->ftrace_enabled to zero. There are two paths through which we enter/exit a guest: 1. If we are the vcore runner, then we enter the guest via __kvmppc_vcore_entry() and we disable ftrace around this. This is always the case for Power9, and for the primary thread on Power8. 2. If we are a secondary thread in Power8, then we would be in nap due to SMT being disabled. We are woken up by an IPI to enter the guest. In this scenario, we enter the guest through kvm_start_guest(). We disable ftrace at this point. In this scenario, ftrace would only get re-enabled on the secondary thread when SMT is re-enabled (via start_secondary()). Signed-off-by:
-
Naveen N. Rao authored
Disable ftrace when a cpu is about to go offline. When the cpu is woken up, ftrace will get enabled in start_secondary(). Signed-off-by:
-
Naveen N. Rao authored
On the boot cpu, though we enable paca->ftrace_enabled in early_setup() (via cpu_ready_for_interrupts()), we don't start tracing until much later since ftrace is not initialized yet and since we only support DYNAMIC_FTRACE on powerpc. However, it is possible that ftrace has been initialized by the time some of the secondary cpus start up. In this case, we will try to trace some of the early boot code which can cause problems. To address this, move setting paca->ftrace_enabled from cpu_ready_for_interrupts() to early_setup() for the boot cpu, and towards the end of start_secondary() for secondary cpus. Signed-off-by:
-
