Re: [PATCH] powerpc64s: Print exception vector name alongside the trap number

Benjamin Herrenschmidt wrote: On Wed, 2018-04-18 at 14:32 +0530, Naveen N. Rao wrote: +#ifdef CONFIG_PPC_BOOK3S_64 +static char *print_trap(unsigned long trapno) +{ + trapno &= 0xff0; + switch (trapno) { + case 0x100: return "SRESET"; + case 0x200:

[PATCH v5 09/10] powerpc64/ftrace: Use the generic version of ftrace_replace_code()

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 --- arch/powerpc/kernel/trace/ftrace.c | 36

[PATCH v5 00/10] powerpc64/ftrace: Add support for ftrace_modify_call() and a few other fixes

This is v5 of the patches posted at: https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=37250 This series has been tested using mambo for p8 (hash) and p9 (radix), and also on Power8 host. In v5, the patch for KVM has been re-worked and is now [6/10], instead of [2/10]. This now

[PATCH v5 10/10] powerpc64/ftrace: Implement support for ftrace_regs_caller()

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

[PATCH v5 03/10] powerpc64/ftrace: Add helpers to hard disable ftrace

Add some helpers to enable/disable ftrace through paca->ftrace_enabled. Signed-off-by: Naveen N. Rao --- arch/powerpc/include/asm/ftrace.h | 17 + 1 file changed, 17 insertions(+) diff --git a/arch/powerpc/include/asm/ftrace.h

[PATCH v5 02/10] powerpc64/ftrace: Rearrange #ifdef sections in ftrace.h

Re-arrange the last #ifdef section in preparation for a subsequent change. Signed-off-by: Naveen N. Rao --- arch/powerpc/include/asm/ftrace.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/ftrace.h

[PATCH v5 06/10] powerpc64/ftrace: Disable ftrace during kvm entry/exit

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

[PATCH v5 01/10] powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code paths

We have some C code that we call into from real mode where we cannot take any exceptions. Though the C functions themselves are mostly safe, if these functions are traced, there is a possibility that we may take an exception. For instance, in certain conditions, the ftrace code uses WARN(), which

[PATCH v5 05/10] powerpc64/ftrace: Disable ftrace during hotplug

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 --- arch/powerpc/kernel/smp.c | 8 1 file changed, 8 insertions(+) diff --git

Re: [RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized

On Wed, Apr 18, 2018 at 09:22:09AM -0500, Eric W. Biederman wrote: > Dave Martin writes: > > > On Tue, Apr 17, 2018 at 02:37:38PM -0500, Eric W. Biederman wrote: [...] > >> My intention is to leave 0 instances of clear_siginfo in the > >> architecture specific code.

[PATCH v5 07/10] powerpc64/kexec: Hard disable ftrace before switching to the new kernel

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

[PATCH v5 04/10] powerpc64/ftrace: Delay enabling ftrace on secondary cpus

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

Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER

On Sun, Apr 15, 2018 at 11:16:04AM -0700, Linus Torvalds wrote: [...] > The other thing we should do is to get rid of the stupid padding. > Right now "struct siginfo" is pointlessly padded to 128 bytes. That is > completely insane, when it's always just zero in the kernel. Agreed, inside the

[PATCH v3 04/17] y2038: s390: Remove unneeded ipc uapi header files

The s390 msgbuf/sembuf/shmbuf header files are all identical to the version from asm-generic. This patch removes the files and replaces them with 'generic-y' statements, to avoid having to modify each copy when we extend sysvipc to deal with 64-bit time_t in 32-bit user space. Note that unlike

[PATCH] powerpc/kvm: Fix lockups when running KVM guests on Power8

When running KVM guests on Power8 we can see a lockup where one CPU stops responding. This often leads to a message such as: watchdog: CPU 136 detected hard LOCKUP on other CPUs 72 Task dump for CPU 72: qemu-system-ppc R running task10560 20917 20908 0x00040004 And then backtraces on

Re: powerpc/eeh: Fix enabling bridge MMIO windows

On Wed, 2018-04-11 at 03:37:58 UTC, Michael Neuling wrote: > On boot we save the configuration space of PCIe bridges. We do this so > when we get an EEH event and everything gets reset that we can restore > them. > > Unfortunately we save this state before we've enabled the MMIO space > on the

Re: powerpc/kvm: Fix lockups when running KVM guests on Power8

On Thu, 2018-04-19 at 13:29:50 UTC, Michael Ellerman wrote: > When running KVM guests on Power8 we can see a lockup where one CPU > stops responding. This often leads to a message such as: > > watchdog: CPU 136 detected hard LOCKUP on other CPUs 72 > Task dump for CPU 72: > qemu-system-ppc

Re: [1/3] powerpc/xive: Fix trying to "push" an already active pool VP

On Wed, 2018-04-11 at 05:17:59 UTC, Benjamin Herrenschmidt wrote: > When setting up a CPU, we "push" (activate) a pool VP for it. > > However it's an error to do so if it already has an active > pool VP. > > This happens when doing soft CPU hotplug on powernv since we > don't tear down the CPU

[PATCH v5 08/10] powerpc64/module: Tighten detection of mcount call sites with -mprofile-kernel

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:

[PATCH v4 3/7] powerpc/fadump: un-register fadump on kexec path.

From: Mahesh Salgaonkar 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

[PATCH v4 1/7] powerpc/fadump: Move the metadata region to start of the reserved area.

From: Mahesh Salgaonkar Currently the metadata region that holds crash info structure and ELF core header is placed towards the end of reserved memory area. This patch places it at the beginning of the reserved memory area. It also introduces additional dump section

[PATCH v4 0/7] powerpc/fadump: Improvements and fixes for firmware-assisted dump.

One of the primary issues with Firmware Assisted Dump (fadump) on Power is that it needs a large amount of memory to be reserved. This reserved memory is used for saving the contents of old crashed kernel's memory before fadump capture kernel uses old kernel's memory area to boot. However, This

Re: [PATCH 1/2] powernv/npu: Add lock to prevent race in concurrent context init/destroy

Sorry, forgot to include: Fixes: 1ab66d1fbada ("powerpc/powernv: Introduce address translation services for Nvlink2") Thanks On Wednesday, 11 April 2018 4:38:54 PM AEST Alistair Popple wrote: > The pnv_npu2_init_context() and pnv_npu2_destroy_context() functions are > used to allocate/free

Re: [PATCH 2/2] powernv/npu: Prevent overwriting of pnv_npu2_init_contex() callback parameters

Sorry, forgot to include: Fixes: 1ab66d1fbada ("powerpc/powernv: Introduce address translation services for Nvlink2") Thanks On Wednesday, 11 April 2018 4:38:55 PM AEST Alistair Popple wrote: > There is a single npu context per set of callback parameters. Callers > should be prevented from

[PATCH v4 4/7] powerpc/fadump: Reservationless firmware assisted dump

From: Mahesh Salgaonkar One of the primary issues with Firmware Assisted Dump (fadump) on Power is that it needs a large amount of memory to be reserved. On large systems with TeraBytes of memory, this reservation can be quite significant. In some cases, fadump fails

Re: [PATCH 1/2] powernv/npu: Do a PID GPU TLB flush when invalidating a large address range

Sorry, forgot to include: Fixes: 1ab66d1fbada ("powerpc/powernv: Introduce address translation services for Nvlink2") Thanks On Tuesday, 17 April 2018 7:11:28 PM AEST Alistair Popple wrote: > The NPU has a limited number of address translation shootdown (ATSD) > registers and the GPU has

[PATCH v4 2/7] powerpc/fadump: Update documentation to reflect the metadata region movement.

From: Mahesh Salgaonkar Metadata region that holds fadump header and ELF header is now placed at the start of reserved memory area. Update the documentation accordingly Signed-off-by: Mahesh Salgaonkar ---

[PATCH v4 7/7] powerpc/fadump: Do not allow hot-remove memory from fadump reserved area.

From: Mahesh Salgaonkar For fadump to work successfully there should not be any holes in reserved memory ranges where kernel has asked firmware to move the content of old kernel memory in event of crash. But this memory area is currently not protected from hot-remove

[PATCH v4 6/7] powerpc/fadump: throw proper error message on fadump registration failure.

From: Mahesh Salgaonkar fadump fails to register when there are holes in reserved memory area. This can happen if user has hot-removed a memory that falls in the fadump reserved memory area. Throw a meaningful error message to the user in such case. Signed-off-by:

[PATCH v4 5/7] powerpc/fadump: Update documentation to reflect CMA reservation.

From: Mahesh Salgaonkar Signed-off-by: Mahesh Salgaonkar --- Documentation/powerpc/firmware-assisted-dump.txt | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/powerpc/firmware-assisted-dump.txt

[PATCH v3 17/17] y2038: compat: Move common compat types to asm-generic/compat.h

The architectures that support 32-bit compat mode define a number of simple types for use in compat handlers. About half of those are identical between architectures, and some of those are also required now by handlers shared with CONFIG_COMPAT_32BIT_TIME functions on 32-bit architectures. Let's

[PATCH v3 10/17] y2038: powerpc: Extend sysvipc data structures

powerpc, uses a nonstandard variation of the generic sysvipc data structures, intended to have the padding moved around so it can deal with big-endian 32-bit user space that has 64-bit time_t. powerpc has the same definition as parisc and sparc, but now also supports little-endian mode, which is

[PATCH v3 16/17] y2038: ipc: Redirect ipc(SEMTIMEDOP, ...) to compat_ksys_semtimedop

32-bit architectures implementing 64BIT_TIME and COMPAT_32BIT_TIME need to have the traditional semtimedop() behavior with 32-bit timestamps for sys_ipc() by calling compat_ksys_semtimedop(), while those that are not yet converted need to keep using ksys_semtimedop() like 64-bit architectures do.

Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

On Thu, Apr 19, 2018 at 4:59 PM, Eric W. Biederman wrote: > Arnd Bergmann writes: >> >> struct msqid64_ds { >> struct ipc64_perm msg_perm; >> +#if __BITS_PER_LONG == 64 >> __kernel_time_t msg_stime; /* last msgsnd time */ >> -#if

[PATCH v3 03/17] y2038: ia64: Remove unneeded ipc uapi header files

The ia64 ipcbuf/msgbuf/sembuf/shmbuf header files are all identical to the version from asm-generic. This patch removes the files and replaces them with 'generic-y' statements as part of the y2038 changes. While ia64 no longer has a compat mode and doesn't need the file any more, it seem nicer to

[PATCH v3 02/17] y2038: alpha: Remove unneeded ipc uapi header files

The alpha ipcbuf/msgbuf/sembuf/shmbuf header files are all identical to the version from asm-generic. This patch removes the files and replaces them with 'generic-y' statements as part of the y2038 series. Since there is no 32-bit syscall support for alpha, we don't need the other changes, but

[PATCH v3 14/17] y2038: ipc: Use __kernel_timespec

This is a preparatation for changing over __kernel_timespec to 64-bit times, which involves assigning new system call numbers for mq_timedsend(), mq_timedreceive() and semtimedop() for compatibility with future y2038 proof user space. The existing ABIs will remain available through compat code.

[PATCH v3 00/17] y2038: Convert IPC syscalls

This is an update of a series I posted a long time ago [1], updating the IPC subsystem to pass down 64-bit time stamps to user space. In particular, for sys_msgctl, sys_semctl and sys_shmctl, I do not introduce a completely new set of replacement system calls, but instead extend the existing ones

[PATCH v3 11/17] y2038: xtensa: Extend sysvipc data structures

xtensa, uses a nonstandard variation of the generic sysvipc data structures, intended to have the padding moved around so it can deal with big-endian 32-bit user space that has 64-bit time_t. xtensa tries hard to define the structures so they work in both big-endian and little-endian systems with

[PATCH v3 15/17] y2038: ipc: Enable COMPAT_32BIT_TIME

Three ipc syscalls (mq_timedsend, mq_timedreceive and and semtimedop) take a timespec argument. After we move 32-bit architectures over to useing 64-bit time_t based syscalls, we need seperate entry points for the old 32-bit based interfaces. This changes the #ifdef guards for the existing 32-bit

Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

Arnd Bergmann writes: > Most architectures now use the asm-generic copy of the sysvipc data > structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit > __kernel_time_t on 32-bit architectures but have padding behind them to > allow extending the type to 64-bit. > >

[PATCH v3 08/17] y2038: parisc: Extend sysvipc data structures

parisc, uses a nonstandard variation of the generic sysvipc data structures, intended to have the padding moved around so it can deal with big-endian 32-bit user space that has 64-bit time_t. Unlike most architectures, parisc actually succeeded in defining this right for big-endian CPUs, but as

[PATCH v3 13/17] y2038: ipc: Report long times to user space

The shmid64_ds/semid64_ds/msqid64_ds data structures have been extended to contain extra fields for storing the upper bits of the time stamps, this patch does the other half of the job and and fills the new fields on 32-bit architectures as well as 32-bit tasks running on a 64-bit kernel in compat

Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER

Dave Martin writes: > On Sun, Apr 15, 2018 at 11:16:04AM -0700, Linus Torvalds wrote: > > [...] > >> The other thing we should do is to get rid of the stupid padding. >> Right now "struct siginfo" is pointlessly padded to 128 bytes. That is >> completely insane, when it's

[PATCH v3 05/17] y2038: arm64: Extend sysvipc compat data structures

Both 32-bit amd 64-bit ARM use the asm-generic header files for their sysvipc data structures, so no special care is needed to make those work beyond y2038, with the one exception of compat mode: Since there is no asm-generic definition of the compat mode IPC structures, ARM64 provides its own

[PATCH v3 06/17] y2038: mips: Extend sysvipc data structures

MIPS is the weirdest case for sysvipc, because each of the three data structures is done differently: * msqid64_ds has padding in the right place so we could in theory extend this one to just have 64-bit values instead of time_t. As this does not work for most of the other combinations, we

[PATCH v3 07/17] y2038: x86: Extend sysvipc data structures

This extends the x86 copy of the sysvipc data structures to deal with 32-bit user space that has 64-bit time_t and wants to see timestamps beyond 2038. Fortunately, x86 has padding for this purpose in all the data structures, so we can just add extra fields. With msgid64_ds and shmid64_ds, the

[PATCH v3 12/17] y2038: ipc: Use ktime_get_real_seconds consistently

In some places, we still used get_seconds() instead of ktime_get_real_seconds(), and I'm changing the remaining ones now to all use ktime_get_real_seconds() so we use the full available range for timestamps instead of overflowing the 'unsigned long' return value in year 2106 on 32-bit kernels.

[PATCH v3 09/17] y2038: sparc: Extend sysvipc data structures

sparc, uses a nonstandard variation of the generic sysvipc data structures, intended to have the padding moved around so it can deal with big-endian 32-bit user space that has 64-bit time_t. Unlike most architectures, sparc actually succeeded in defining this right for big-endian CPUs, but as

[PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

Most architectures now use the asm-generic copy of the sysvipc data structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit __kernel_time_t on 32-bit architectures but have padding behind them to allow extending the type to 64-bit. Unfortunately, that fails on all big-endian

Re: [PATCH] kvm: Change return type to vm_fault_t

On Thu, 19 Apr 2018 00:49:58 +0530 Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will become a

[PATCH 00/61] tree-wide: simplify getting .drvdata

I got tired of fixing this in Renesas drivers manually, so I took the big hammer. Remove this cumbersome code pattern which got copy-pasted too much already: - struct platform_device *pdev = to_platform_device(dev); - struct ep93xx_keypad *keypad = platform_get_drvdata(pdev); +

Re: [PATCH v5 00/10] powerpc64/ftrace: Add support for ftrace_modify_call() and a few other fixes

On Thu, 19 Apr 2018 12:33:59 +0530 "Naveen N. Rao" wrote: > This is v5 of the patches posted at: > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=37250 > > This series has been tested using mambo for p8 (hash) and p9 (radix), > and also on

Re: [PATCH v5 06/10] powerpc64/ftrace: Disable ftrace during kvm entry/exit

On Thu, 19 Apr 2018 12:34:05 +0530 "Naveen N. Rao" wrote: > 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

[PATCH 07/61] dma: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/dma/at_hdmac.c | 9 +++--

Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

Arnd Bergmann writes: > On Thu, Apr 19, 2018 at 5:20 PM, Arnd Bergmann wrote: >> On Thu, Apr 19, 2018 at 4:59 PM, Eric W. Biederman >> wrote: >>> I suspect you want to use __kernel_ulong_t here instead of a raw >>> unsigned long. If

Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

On Thu, Apr 19, 2018 at 5:20 PM, Arnd Bergmann wrote: > On Thu, Apr 19, 2018 at 4:59 PM, Eric W. Biederman > wrote: >> I suspect you want to use __kernel_ulong_t here instead of a raw >> unsigned long. If nothing else it seems inconsistent to use typedefs

[REVIEW][PATCH 17/17] signal/powerpc: Replace TRAP_FIXME with TRAP_UNK

Using an si_code of 0 that aliases with SI_USER is clearly the wrong thing todo, and causes problems in interesting ways. For use in unknown_exception the recently defined TRAP_UNK semantically is a perfect fit. For use in RunModeException it looks like something more specific than TRAP_UNK

[REVIEW][PATCH 15/17] signal: Add TRAP_UNK si_code for undiagnosted trap exceptions

Both powerpc and alpha have cases where they wronly set si_code to 0 in combination with SIGTRAP and don't mean SI_USER. About half the time this is because the architecture can not report accurately what kind of trap exception triggered the trap exception. The other half the time it looks like

[REVIEW][PATCH 13/17] signal/powerpc: Replace FPE_FIXME with FPE_FLTUNK

Using an si_code of 0 that aliases with SI_USER is clearly the wrong thing todo, and causes problems in interesting ways. The newly defined FPE_FLTUNK semantically appears to fit the bill so use it instead. Cc: Paul Mackerras Cc: Kumar Gala Cc: