Re: [linux-next] cpus stalls detected few hours after booting next kernel

On Fri, 2017-06-30 at 00:45 +1000, Nicholas Piggin wrote: > On Thu, 29 Jun 2017 20:23:05 +1000 > Nicholas Piggin wrote: > > > On Thu, 29 Jun 2017 19:36:14 +1000 > > Nicholas Piggin wrote: > > > > I don't *think* the replay-wakeup-interrupt patch is

Re: [1/3] cpuidle: powerpc: cpuidle set polling before enabling irqs

"Rafael J. Wysocki" writes: > On Thu, Jun 29, 2017 at 2:21 PM, Michael Ellerman > wrote: >> On Wed, 2017-06-14 at 13:02:39 UTC, Nicholas Piggin wrote: >>> local_irq_enable can cause interrupts to be taken which could >>> take significant

Re: kworker with empty task->cpus_allowed (was Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host)

Tejun Heo writes: > Hello, > > Could be the same problem as the one reported in the following thread. > > http://lkml.kernel.org/r/1497266622.15415.39.ca...@abdul.in.ibm.com > > The root cause there is ppc arch code not setting up possible cpu <-> > numa mapping during boot.

[PATCH 2/2] powerpc/tm: test for regs sanity in VSX exception

Add a test to check if FP/VSX registers are sane (restored correctly) after a VSX unavailable exception is caught in the middle of a transaction. Signed-off-by: Gustavo Romero Signed-off-by: Breno Leitao ---

[PATCH 1/2] powerpc/tm: fix live state of vs0/32 in tm_reclaim

Currently tm_reclaim() can return with a corrupted vs0 (fp0) or vs32 (v0) due to the fact vs0 is used to save FPSCR and vs32 is used to save VSCR. Later, we recheckpoint trusting that the live state of FP and VEC are ok depending on the MSR.FP and MSR.VEC bits, i.e. if MSR.FP is enabled that

[PATCH RFC 21/26] powerpc: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

Re: [PATCH] scsi: ibmvfc: constify dev_pm_ops structures.

On 06/29/2017 12:54 AM, Arvind Yadav wrote: > dev_pm_ops are not supposed to change at runtime. All functions > working with dev_pm_ops provided by work with const > dev_pm_ops. So mark the non-const structs as const. > > File size before: >text data bss dec hex filename

Re: [PATCH] scsi: ibmvscsi: constify dev_pm_ops structures.

On 06/29/2017 12:43 AM, Arvind Yadav wrote: > dev_pm_ops are not supposed to change at runtime. All functions > working with dev_pm_ops provided by work with const > dev_pm_ops. So mark the non-const structs as const. > > File size before: >text data bss dec hex filename

[PATCH v3 8/8] powerpc/perf/hv-24x7: Aggregate result elements on POWER9 SMT8

On POWER9 SMT8 the 24x7 API returns two result elements for physical core and virtual CPU events and we need to add their counts to get the final result. Reviewed-by: Sukadev Bhattiprolu Signed-off-by: Thiago Jung Bauermann ---

[PATCH v3 7/8] powerpc/perf/hv-24x7: Support v2 of the hypervisor API

POWER9 introduces a new version of the hypervisor API to access the 24x7 perf counters. The new version changed some of the structures used for requests and results. Signed-off-by: Thiago Jung Bauermann --- arch/powerpc/perf/hv-24x7.c| 135

[PATCH v3 6/8] powerpc/perf/hv-24x7: Minor improvements

There's an H24x7_DATA_BUFFER_SIZE constant, so use it in init_24x7_request. There's also an HV_PERF_DOMAIN_MAX constant, so use it in h_24x7_event_init. This makes the comment above the check redundant, so remove it. In add_event_to_24x7_request, a statement is terminated with a comma instead of

[PATCH v3 5/8] powerpc/perf/hv-24x7: Fix return value of hcalls

The H_GET_24X7_CATALOG_PAGE hcall can return a signed error code, so fix this in the code. The H_GET_24X7_DATA hcall can return a signed error code, so fix this in the code. Also, don't truncate it to 32 bit to use as return value for make_24x7_request. In case of error h_24x7_event_commit_txn

[PATCH v3 4/8] powerpc-perf/hx-24x7: Don't log failed hcall twice

make_24x7_request already calls log_24x7_hcall if it fails, so callers don't have to do it again. In fact, since the latter is now only called from the former, there's no need for a separate log_24x7_hcall anymore so remove it. Reviewed-by: Sukadev Bhattiprolu

[PATCH v3 3/8] powerpc/perf/hv-24x7: Properly iterate through results

hv-24x7.h has a comment mentioning that result_buffer->results can't be indexed as a normal array because it may contain results of variable sizes, so fix the loop in h_24x7_event_commit_txn to take the variation into account when iterating through results. Another problem in that loop is that it

[PATCH v3 2/8] powerpc/perf/hv-24x7: Fix off-by-one error in request_buffer check

request_buffer can hold 254 requests, so if it already has that number of entries we can't add a new one. Also, define constant to show where the number comes from. Fixes: e3ee15dc5d19 ("powerpc/perf/hv-24x7: Define add_event_to_24x7_request()") Reviewed-by: Sukadev Bhattiprolu

[PATCH v3 1/8] powerpc/perf/hv-24x7: Fix passing of catalog version number

H_GET_24X7_CATALOG_PAGE needs to be passed the version number obtained from the first catalog page obtained previously. This is a 64 bit number, but create_events_from_catalog truncates it to 32-bit. This worked on POWER8, but POWER9 actually uses the upper bits so the call fails with H_P3

[PATCH v3 0/8] Support for 24x7 hcall interface version 2

Hello, The hypervisor interface to access 24x7 performance counters (which collect performance information from system power on to system power off) has been extended in POWER9 adding new fields to the request and result element structures. Also, results for some domains now return more than one

Re: [1/3] cpuidle: powerpc: cpuidle set polling before enabling irqs

On Thu, Jun 29, 2017 at 2:21 PM, Michael Ellerman wrote: > On Wed, 2017-06-14 at 13:02:39 UTC, Nicholas Piggin wrote: >> local_irq_enable can cause interrupts to be taken which could >> take significant amount of processing time. The idle process >> should set

Re: [PATCH kernel 0/3 REPOST] vfio-pci: Add support for mmapping MSI-X table

On Wed, 28 Jun 2017 17:27:32 +1000 Alexey Kardashevskiy wrote: > On 24/06/17 01:17, Alex Williamson wrote: > > On Fri, 23 Jun 2017 15:06:37 +1000 > > Alexey Kardashevskiy wrote: > > > >> On 23/06/17 07:11, Alex Williamson wrote: > >>> On Thu, 15 Jun 2017

[PATCH] ptrace: Add compat PTRACE_{G,S}ETSIGMASK handlers

compat_ptrace_request() lacks handlers for PTRACE_{G,S}ETSIGMASK, instead using those in ptrace_request(). The compat variant should read a compat_sigset_t from userspace instead of ptrace_request()s sigset_t. While compat_sigset_t is the same size as sigset_t, it is defined as 2xu32, instead of

Re: [linux-next] cpus stalls detected few hours after booting next kernel

[ Adding my IMAP address on CC to avoid another Lotus Notes reply to LKML. Man, it has been more than 15 years since the last one!!! ] Nicholas Piggin wrote on 06/29/2017 07:45:34 AM: > On Thu, 29 Jun 2017 20:23:05 +1000 > Nicholas Piggin wrote: > > > On

Re: [PATCH] net: ibm: ibmveth: constify dev_pm_ops structures.

From: Arvind Yadav Date: Thu, 29 Jun 2017 11:14:50 +0530 > dev_pm_ops are not supposed to change at runtime. All functions > working with dev_pm_ops provided by work with const > dev_pm_ops. So mark the non-const structs as const. > > File size before: >text

Re: [PATCH V6] powerpc/powernv : Add support for OPAL-OCC command/response interface

Hi, On 06/30/2017 12:02 AM, Shilpasri G Bhat wrote: > In P9, OCC (On-Chip-Controller) supports shared memory based > commad-response interface. Within the shared memory there is an OPAL > command buffer and OCC response buffer that can be used to send > inband commands to OCC. This patch adds a

[PATCH V6] powerpc/powernv : Add support for OPAL-OCC command/response interface

In P9, OCC (On-Chip-Controller) supports shared memory based commad-response interface. Within the shared memory there is an OPAL command buffer and OCC response buffer that can be used to send inband commands to OCC. This patch adds a platform driver to support the command/response interface

Re: [PATCH V5] powerpc/powernv : Add support for OPAL-OCC command/response interface

On 06/27/2017 10:05 AM, Cyril Bur wrote: > On Mon, 2017-06-26 at 11:02 +0530, Shilpasri G Bhat wrote: >> In P9, OCC (On-Chip-Controller) supports shared memory based >> commad-response interface. Within the shared memory there is an OPAL >> command buffer and OCC response buffer that can be used

[PATCH v5 7/7] powerpc/64s: Blacklist rtas entry/exit from kprobes

We can't take traps with relocation off, so blacklist enter_rtas() and rtas_return_loc(). However, instead of blacklisting all of enter_rtas(), introduce a new symbol __enter_rtas from where on we can't take a trap and blacklist that. Signed-off-by: Naveen N. Rao

[PATCH v5 6/7] powerpc/64s: Blacklist functions invoked on a trap

Blacklist all functions involved while handling a trap. We: - convert some of the symbols into private symbols, and - blacklist most functions involved while handling a trap. Reviewed-by: Masami Hiramatsu Signed-off-by: Naveen N. Rao ---

[PATCH v5 5/7] powerpc/64s: Un-blacklist system_call() from kprobes

It is actually safe to probe system_call() in entry_64.S, but only till we unset MSR_RI. To allow this, add a new symbol system_call_exit() after the mtmsrd and blacklist that. Suggested-by: Michael Ellerman Reviewed-by: Nicholas Piggin Signed-off-by:

[PATCH v5 4/7] powerpc/64s: Move system_call() symbol to just after setting MSR_EE

It is common to get a PMU interrupt right after the mtmsr instruction that enables interrupts. Due to this, the stack trace profile gets needlessly split across system_call_common() and system_call(). Previously, system_call() symbol was at the current place to hide a few earlier symbols which

[PATCH v5 3/7] powerpc/64s: Blacklist system_call() and system_call_common() from kprobes

Convert some of the symbols into private symbols and blacklist system_call_common() and system_call() from kprobes. We can't take a trap at parts of these functions as either MSR_RI is unset or the kernel stack pointer is not yet setup. Reviewed-by: Masami Hiramatsu

[PATCH v5 2/7] powerpc/64s: Convert .L__replay_interrupt_return to a local label

Commit b48bbb82e2b835 ("powerpc/64s: Don't unbalance the return branch predictor in __replay_interrupt()") introduced __replay_interrupt_return symbol with '.L' prefix in hopes of keeping it private. However, due to the use of LOAD_REG_ADDR(), the assembler kept this symbol visible. Fix the same

[PATCH v5 1/7] powerpc64/elfv1: Only dereference function descriptor for non-text symbols

Currently, we assume that the function pointer we receive in ppc_function_entry() points to a function descriptor. However, this is not always the case. In particular, assembly symbols without the right annotation do not have an associated function descriptor. Some of these symbols are added to

[PATCH v5 0/7] powerpc: build out kprobes blacklist -- series 3

This is the third in the series of patches to build out an appropriate kprobes blacklist for powerpc. Since posting the second series (*), there have been related changes to the code and I have brought that series forward to account for those changes. As such, all patches from the second series

Re: [PATCH v4 7/7] powerpc/64s: Blacklist rtas entry/exit from kprobes

On 2017/06/29 10:13PM, Nicholas Piggin wrote: > On Thu, 29 Jun 2017 17:24:14 +0530 > "Naveen N. Rao" wrote: > > > On 2017/06/29 09:01PM, Nicholas Piggin wrote: > > > On Thu, 29 Jun 2017 16:11:10 +0530 > > > "Naveen N. Rao" wrote:

Re: [linux-next] cpus stalls detected few hours after booting next kernel

On Thu, 29 Jun 2017 20:23:05 +1000 Nicholas Piggin wrote: > On Thu, 29 Jun 2017 19:36:14 +1000 > Nicholas Piggin wrote: > > I don't *think* the replay-wakeup-interrupt patch is directly involved, but > > it's likely to be one of the idle patches. Okay

Re: kworker with empty task->cpus_allowed (was Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host)

Hello, Could be the same problem as the one reported in the following thread. http://lkml.kernel.org/r/1497266622.15415.39.ca...@abdul.in.ibm.com The root cause there is ppc arch code not setting up possible cpu <-> numa mapping during boot. Thanks. -- tejun

Re: kworker with empty task->cpus_allowed (was Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host)

On Thu, Jun 29, 2017 at 10:06:31PM +1000, Michael Ellerman wrote: > Eryu Guan writes: > > > On Thu, Jun 29, 2017 at 09:12:55PM +1000, Michael Ellerman wrote: > >> Eryu Guan writes: > >> > >> > On Thu, Jun 29, 2017 at 06:47:50PM +1000, Balbir Singh wrote: >

Re: [PATCH] powerpc/powernv: Tell OPAL about our MMU mode

On Thu, 2017-06-29 at 15:24 +1000, Michael Ellerman wrote: > Benjamin Herrenschmidt writes: > > > On Wed, 2017-06-28 at 15:17 +1000, Michael Ellerman wrote: > > > Which doesn't really make sense. FSP says it's running (runtime). > > > > > > The end of the OPAL log is

[PATCH v2 4/4] selftests/ftrace: Add a testcase for kprobe event naming

From: Masami Hiramatsu Add a testcase for kprobe event naming. This testcase checks whether the kprobe events can automatically ganerate its event name on normal function and dot-suffixed function. Also it checks whether the kprobe events can correctly define new event with

[PATCH v2 3/4] selftests/ftrace: Update multiple kprobes test for powerpc

KPROBES_ON_FTRACE is only available on powerpc64le. Update comment to clarify this. Also, we should use an offset of 8 to ensure that the probe does not fall on ftrace location. The current offset of 4 will fall before the function local entry point and won't fire, while an offset of 12 or 16

[PATCH v2 2/4] selftests/ftrace: Add a test to probe module functions

Add a kprobes test to ensure that we are able to add a probe on a module function using 'p :' format, without having to specify a probe name. Suggested-by: Masami Hiramatsu Acked-by: Masami Hiramatsu Signed-off-by: Naveen N. Rao

[PATCH v2 0/4] A fix and a few new tests for kprobe tracer

v1: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1427923.html Changes since v1: - Patch 1 is unchanged from v1. - Patch 3 drops change to include dot symbols, as suggested by Masami. - Patches 2 and 4 implement new test cases to cover these scenarios Thanks, Naveen Masami

[PATCH v2 1/4] trace/kprobes: Sanitize derived event names

When we derive event names, convert some expected symbols (such as ':' used to specify module:name and '.' present in some symbols) into underscores so that the event name is not rejected. Before this patch: # echo 'p kobject_example:foo_store' > kprobe_events trace_kprobe: Failed to

Re: [PATCH 2/2] selftests/ftrace: Update multiple kprobes test for powerpc

On 2017/06/29 09:57AM, Masami Hiramatsu wrote: > On Thu, 29 Jun 2017 00:13:24 +0530 > "Naveen N. Rao" wrote: > > > On 2017/06/28 11:16PM, Masami Hiramatsu wrote: > > > > > diff --git > > > > > a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc >

Re: powernv:idle: Clear r12 on wakeup from stop lite

On Wed, 2017-06-28 at 01:16:49 UTC, Akshay Adiga wrote: > pnv_wakeup_noloss expects R12 to contain SRR1 value to determine if > the wakeup reason is an HMI in CHECK_HMI_INTERRUPT. > > When we wakeup with ESL=0, SRR1 will not contain the wakeup reason, so > there is no point setting R12 to SRR1. >

Re: [1/2] powerpc/smp: Do not BUG_ON if invalid CPU during kick

On Tue, 2017-06-27 at 07:00:05 UTC, Santosh Sivaraj wrote: > During secondary start, we do not need to BUG_ON if an invalid CPU number > is passed. We already print an error if secondary cannot be started, so > just return an error instead. > > Signed-off-by: Santosh Sivaraj

Re: powerpc: Only do ERAT invalidate on radix context switch on P9 DD1

On Sun, 2017-06-25 at 20:08:46 UTC, Benjamin Herrenschmidt wrote: > From: Michael Neuling > > On P9 (Nimbus) DD2 and later, in radix mode, the move to the PID > register will implicitly invalidate the user space ERAT entries > and leave the kernel ones alone. Thus the only

Re: powerpc/perf: Fix branch event code for power9

On Sun, 2017-06-25 at 15:34:46 UTC, Madhavan Srinivasan wrote: > Correct "branch" event code of Power9 is "r4d05e". > Replace the current "branch" event code with "r4d05e" > and add a hack to use "r10012" as event code for > power9 dd1. > > Fixes: d89f473ff6f8 ("powerpc/perf: Fix PM_BRU_CMPL

Re: powerpc/xive: Silence message about VP block allocation

On Sat, 2017-06-24 at 19:57:27 UTC, Benjamin Herrenschmidt wrote: > There is no reason for that message to be pr_info(), it will be printed > every time we start a KVM guest. > > Signed-off-by: Benjamin Herrenschmidt Applied to powerpc next, thanks.

Re: [v2] powerpc: Invalidate ERAT on powersave wakeup for POWER9

On Sat, 2017-06-24 at 17:29:01 UTC, Benjamin Herrenschmidt wrote: > On POWER9 the ERAT may be incorrect on wakeup from some stop states > that lose state. This causes random segvs and illegal instructions > when these stop states are enabled. > > This patch invalidates the ERAT on wakeup on

Re: [1/2] powerpc/powernv/pci: Add helper to check if a PE has a single vendor

On Wed, 2017-06-21 at 07:18:03 UTC, Russell Currey wrote: > Add a helper that determines if all the devices contained in a given PE > are all from the same vendor or not. This can be useful in determining > if it's okay to make PE-wide changes that may be suitable for some > devices but not for

Re: [RESEND, v5, 16/16] powerpc/44x: Add generic compatible string for I2C EEPROM

On Thu, 2017-06-15 at 18:54:18 UTC, Javier Martinez Canillas wrote: > The at24 driver allows to register I2C EEPROM chips using different vendor > and devices, but the I2C subsystem does not take the vendor into account > when matching using the I2C table since it only has device entries. > > But

Re: [RESEND, v5, 15/16] powerpc/83xx: Add generic compatible string for I2C EEPROM

On Thu, 2017-06-15 at 18:54:17 UTC, Javier Martinez Canillas wrote: > The at24 driver allows to register I2C EEPROM chips using different vendor > and devices, but the I2C subsystem does not take the vendor into account > when matching using the I2C table since it only has device entries. > > But

Re: [RESEND, v5, 14/16] powerpc/512x: Add generic compatible string for I2C EEPROM

On Thu, 2017-06-15 at 18:54:16 UTC, Javier Martinez Canillas wrote: > The at24 driver allows to register I2C EEPROM chips using different vendor > and devices, but the I2C subsystem does not take the vendor into account > when matching using the I2C table since it only has device entries. > > But

Re: [RESEND, v5, 13/16] powerpc/fsl: Add generic compatible string for I2C EEPROM

On Thu, 2017-06-15 at 18:54:15 UTC, Javier Martinez Canillas wrote: > The at24 driver allows to register I2C EEPROM chips using different vendor > and devices, but the I2C subsystem does not take the vendor into account > when matching using the I2C table since it only has device entries. > > But

Re: [RESEND, v5, 12/16] powerpc/5200: Add generic compatible string for I2C EEPROM

On Thu, 2017-06-15 at 18:54:14 UTC, Javier Martinez Canillas wrote: > The at24 driver allows to register I2C EEPROM chips using different vendor > and devices, but the I2C subsystem does not take the vendor into account > when matching using the I2C table since it only has device entries. > > But

Re: powerpc: Fix /proc/cpuinfo revision for POWER9 DD2

On Thu, 2017-06-15 at 01:53:16 UTC, Michael Neuling wrote: > The P9 PVR bits 12-15 don't indicate a revision but instead different > chip configurations. From BookIV we have: >Bits Configuration > 0 :Scale out 12 cores > 1 :Scale out 24 cores > 2 :Scale up 12

Re: [1/3] cpuidle: powerpc: cpuidle set polling before enabling irqs

On Wed, 2017-06-14 at 13:02:39 UTC, Nicholas Piggin wrote: > local_irq_enable can cause interrupts to be taken which could > take significant amount of processing time. The idle process > should set its polling flag before this, so another process that > wakes it during this time will not have to

Re: [v2,1/3] powerpc/powernv/pci: Reduce spam when dumping PEST

On Wed, 2017-06-14 at 04:19:58 UTC, Russell Currey wrote: > Dumping the PE State Tables (PEST) can be highly verbose if a number of PEs > are affected, especially in the case where the whole PHB is frozen and 512 > lines get printed. Check for duplicates when dumping the PEST to reduce > useless

Re: [v2] powerpc/fadump: add reschedule point while releasing memory

On Thu, 2017-06-01 at 19:40:10 UTC, Hari Bathini wrote: > Around 95% of memory is reserved by fadump/capture kernel. All this > memory is freed, one page at a time, on writing '1' to the node > /sys/kernel/fadump_release_mem. On systems with large memory, this > can take a long time to complete,

Re: [v3,1/3] powerpc/fadump: avoid duplicates in crash memory ranges

On Thu, 2017-06-01 at 17:20:38 UTC, Hari Bathini wrote: > fadump sets up crash memory ranges to be used for creating PT_LOAD > program headers in elfcore header. Memory chunk RMA_START through > boot memory area size is added as the first memory range because > firmware, at the time of crash,

Re: powerpc: Fix asm offsets to point to actual FP and VMX regs

On Mon, 2017-05-08 at 06:23:31 UTC, Michael Neuling wrote: > The asm code assumes the FP regs are at the start of fp_state. While > this is true now, it may not always be the case and there is nothing > enforcing it. > > This fixes the asm-offsets to point to the actual FP registers inside > the

Re: powerpc/tm: Fix comment

On Mon, 2017-05-08 at 06:18:31 UTC, Michael Neuling wrote: > Update to real function name. > > Signed-off-by: Michael Neuling Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/2bafb7ffa3e0908ad2e69b94c436a0 cheers

Re: [1/2] powerpc/tracing: Trace TLBIE(L)

On Tue, 2017-04-11 at 05:23:25 UTC, Balbir Singh wrote: > Just a quick patch to trace tlbie(l)'s. The idea being that it can be > enabled when we suspect corruption or when we need to see if we are doing > the right thing during flush. I think the format can be enhanced to > make it nicer (expand

Re: [2/3] powerpc/mm: Add comments to the vmemmap layout

On Thu, 2017-04-06 at 14:14:49 UTC, Anshuman Khandual wrote: > Add some explaination to the layout of vmemmap virtual address > space and how physical page mapping is only used for valid PFNs > present at any point on the system. > > Reviewed-by: Aneesh Kumar K.V

Re: [3/3] powerpc/mm: Add comments on vmemmap physical mapping

On Thu, 2017-04-06 at 14:14:50 UTC, Anshuman Khandual wrote: > Adds some explaination on how the vmemmap based struct page layout's > physical mapping is allocated and tracked through linked list. It > also keeps note of a possible race condition. > > Signed-off-by: Anshuman Khandual

Re: [PATCH v4 7/7] powerpc/64s: Blacklist rtas entry/exit from kprobes

On Thu, 29 Jun 2017 17:24:14 +0530 "Naveen N. Rao" wrote: > On 2017/06/29 09:01PM, Nicholas Piggin wrote: > > On Thu, 29 Jun 2017 16:11:10 +0530 > > "Naveen N. Rao" wrote: > > > > > We can't take traps with relocation off, so

Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host

Eryu Guan writes: > On Thu, Jun 29, 2017 at 08:27:11PM +1000, Michael Ellerman wrote: >> Eryu Guan writes: >> >> > Hi all, >> > >> > Li Wang and I are constantly seeing ppc64le hosts crashing due to bad >> > page access. But it's not reproducing on every

kworker with empty task->cpus_allowed (was Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host)

Eryu Guan writes: > On Thu, Jun 29, 2017 at 09:12:55PM +1000, Michael Ellerman wrote: >> Eryu Guan writes: >> >> > On Thu, Jun 29, 2017 at 06:47:50PM +1000, Balbir Singh wrote: >> >> On Thu, Jun 29, 2017 at 1:41 PM, Eryu Guan wrote: >> >>

[PATCH v2] powerpc/kexec: Fix radix to hash kexec

This patch fixes a crash seen while doing a kexec from radix mode to hash mode. Key 0 is special in hash and used in the RPN by default, we set the key values to 0 today. In radix mode key 0 is used to control supervisor<->user access. In hash key 0 is used by default, so the first instruction

Re: [PATCH v4 7/7] powerpc/64s: Blacklist rtas entry/exit from kprobes

On 2017/06/29 09:01PM, Nicholas Piggin wrote: > On Thu, 29 Jun 2017 16:11:10 +0530 > "Naveen N. Rao" wrote: > > > We can't take traps with relocation off, so blacklist enter_rtas() and > > rtas_return_loc(). However, instead of blacklisting all of enter_rtas(), >

Re: [PATCH] powerpc/kexec: Fix radix to hash kexec

On Thu, Jun 29, 2017 at 7:29 PM, Michael Ellerman wrote: > Balbir Singh writes: > >> This patch fixes a crash seen while doing a kexec from >> radix mode to hash mode. Key 0 is special in hash and >> used in the RPN by default, we set the key values to

Re: [PATCH v4 5/7] powerpc/64s: Un-blacklist system_call() from kprobes

On 2017/06/29 08:55PM, Nicholas Piggin wrote: > On Thu, 29 Jun 2017 16:11:08 +0530 > "Naveen N. Rao" wrote: > > > It is actually safe to probe system_call() in entry_64.S, but only till > > we unset MSR_RI. To allow this, add a new symbol system_call_exit() > >

Re: [PATCH v4 1/7] powerpc64/elfv1: Only dereference function descriptor for non-text symbols

On 2017/06/29 08:49PM, Nicholas Piggin wrote: > On Thu, 29 Jun 2017 16:11:04 +0530 > "Naveen N. Rao" wrote: > > > Currently, we assume that the function pointer we receive in > > ppc_function_entry() points to a function descriptor. However, this is > > not

Re: [PATCH v4 4/7] powerpc/64s: Move system_call() symbol to just after setting MSR_EE

On Thu, 29 Jun 2017 16:11:07 +0530 "Naveen N. Rao" wrote: > It is common to get a PMU interrupt right after the mtmsr instruction that > enables interrupts. Due to this, the stack trace profile gets needlessly split > across system_call_common() and

Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host

On Thu, Jun 29, 2017 at 09:12:55PM +1000, Michael Ellerman wrote: > Eryu Guan writes: > > > On Thu, Jun 29, 2017 at 06:47:50PM +1000, Balbir Singh wrote: > >> On Thu, Jun 29, 2017 at 1:41 PM, Eryu Guan wrote: > >> > On Thu, Jun 29, 2017 at 03:16:10AM +1000,

Re: [PATCH v5 2/7] powerpc/vmlinux.lds: Align __init_begin to 16M

On Thu, Jun 29, 2017 at 9:29 PM, David Laight wrote: > From: Balbir Singh >> Sent: 28 June 2017 18:04 >> For CONFIG_STRICT_KERNEL_RWX align __init_begin to 16M. >> We use 16M since its the larger of 2M on radix and 16M >> on hash for our linear mapping. The plan is to

RE: [PATCH v5 2/7] powerpc/vmlinux.lds: Align __init_begin to 16M

From: Balbir Singh > Sent: 28 June 2017 18:04 > For CONFIG_STRICT_KERNEL_RWX align __init_begin to 16M. > We use 16M since its the larger of 2M on radix and 16M > on hash for our linear mapping. The plan is to have > .text, .rodata and everything upto __init_begin marked > as RX. Note we still

Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host

Eryu Guan writes: > On Thu, Jun 29, 2017 at 06:47:50PM +1000, Balbir Singh wrote: >> On Thu, Jun 29, 2017 at 1:41 PM, Eryu Guan wrote: >> > On Thu, Jun 29, 2017 at 03:16:10AM +1000, Balbir Singh wrote: >> >> On Wed, Jun 28, 2017 at 6:32 PM, Eryu Guan

Re: [PATCH v4 7/7] powerpc/64s: Blacklist rtas entry/exit from kprobes

On Thu, 29 Jun 2017 16:11:10 +0530 "Naveen N. Rao" wrote: > We can't take traps with relocation off, so blacklist enter_rtas() and > rtas_return_loc(). However, instead of blacklisting all of enter_rtas(), > introduce a new symbol __enter_rtas from where on we

Re: [PATCH v4 5/7] powerpc/64s: Un-blacklist system_call() from kprobes

On Thu, 29 Jun 2017 16:11:08 +0530 "Naveen N. Rao" wrote: > It is actually safe to probe system_call() in entry_64.S, but only till > we unset MSR_RI. To allow this, add a new symbol system_call_exit() > after the mtmsrd and blacklist that. Though the mtmsrd

Re: [PATCH v4 1/7] powerpc64/elfv1: Only dereference function descriptor for non-text symbols

On Thu, 29 Jun 2017 16:11:04 +0530 "Naveen N. Rao" wrote: > Currently, we assume that the function pointer we receive in > ppc_function_entry() points to a function descriptor. However, this is > not always the case. In particular, assembly symbols without the

[PATCH v4 7/7] powerpc/64s: Blacklist rtas entry/exit from kprobes

We can't take traps with relocation off, so blacklist enter_rtas() and rtas_return_loc(). However, instead of blacklisting all of enter_rtas(), introduce a new symbol __enter_rtas from where on we can't take a trap and blacklist that. Signed-off-by: Naveen N. Rao

[PATCH v4 5/7] powerpc/64s: Un-blacklist system_call() from kprobes

It is actually safe to probe system_call() in entry_64.S, but only till we unset MSR_RI. To allow this, add a new symbol system_call_exit() after the mtmsrd and blacklist that. Though the mtmsrd instruction itself is now whitelisted, we won't be allowed to probe on it as we don't allow probing on

[PATCH v4 6/7] powerpc/64s: Blacklist functions invoked on a trap

Blacklist all functions involved while handling a trap. We: - convert some of the symbols into private symbols, and - blacklist most functions involved while handling a trap. Reviewed-by: Masami Hiramatsu Signed-off-by: Naveen N. Rao ---

[PATCH v4 4/7] powerpc/64s: Move system_call() symbol to just after setting MSR_EE

It is common to get a PMU interrupt right after the mtmsr instruction that enables interrupts. Due to this, the stack trace profile gets needlessly split across system_call_common() and system_call(). Previously, system_call() symbol was at the current place to hide a few earlier symbols which

[PATCH v4 2/7] powerpc/64s: Convert .L__replay_interrupt_return to a local label

Commit b48bbb82e2b835 ("powerpc/64s: Don't unbalance the return branch predictor in __replay_interrupt()") introduced __replay_interrupt_return symbol with '.L' prefix in hopes of keeping it private. However, due to the use of LOAD_REG_ADDR(), the assembler kept this symbol visible. Fix the same

[PATCH v4 3/7] powerpc/64s: Blacklist system_call() and system_call_common() from kprobes

Convert some of the symbols into private symbols and blacklist system_call_common() and system_call() from kprobes. We can't take a trap at parts of these functions as either MSR_RI is unset or the kernel stack pointer is not yet setup. Reviewed-by: Masami Hiramatsu

[PATCH v4 1/7] powerpc64/elfv1: Only dereference function descriptor for non-text symbols

Currently, we assume that the function pointer we receive in ppc_function_entry() points to a function descriptor. However, this is not always the case. In particular, assembly symbols without the right annotation do not have an associated function descriptor. Some of these symbols are added to

[PATCH v4 0/7] powerpc: build out kprobes blacklist -- series 3

This is the third in the series of patches to build out an appropriate kprobes blacklist for powerpc. Since posting the second series (*), there have been related changes to the code and I have brought that series forward to account for those changes. As such, all patches from the second series

Re: [PATCH v11 07/10] powerpc/perf: PMU functions for Core IMC and hotplugging

On Thu, 29 Jun 2017, Madhavan Srinivasan wrote: > On Thursday 29 June 2017 01:11 AM, Thomas Gleixner wrote: > Idea is to handle multiple event session for a given core and > yes, my bad, current implementation is racy/broken. > But an alternate approach is to have a per-core mutex and > per-core

Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host

On Thu, Jun 29, 2017 at 08:27:11PM +1000, Michael Ellerman wrote: > Eryu Guan writes: > > > Hi all, > > > > Li Wang and I are constantly seeing ppc64le hosts crashing due to bad > > page access. But it's not reproducing on every ppc64le host we've > > tested, but it usually

Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host

Eryu Guan writes: > Hi all, > > Li Wang and I are constantly seeing ppc64le hosts crashing due to bad > page access. But it's not reproducing on every ppc64le host we've > tested, but it usually happened in filesystem testings. > And I've confirmed that reverting above

Re: [linux-next] cpus stalls detected few hours after booting next kernel

On Thu, 29 Jun 2017 19:36:14 +1000 Nicholas Piggin wrote: > I've seen this as well (or something like it) in mambo at boot, but > it's pretty rare to hit. I'm trying to debug it. > > I'm guessing possibly an idle vs interrupt race. > > > [ 4255.151192] Sending NMI from CPU 5

Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host

On Thu, Jun 29, 2017 at 06:47:50PM +1000, Balbir Singh wrote: > On Thu, Jun 29, 2017 at 1:41 PM, Eryu Guan wrote: > > On Thu, Jun 29, 2017 at 03:16:10AM +1000, Balbir Singh wrote: > >> On Wed, Jun 28, 2017 at 6:32 PM, Eryu Guan wrote: > > >> Thanks for the

Re: [linux-next] cpus stalls detected few hours after booting next kernel

I've seen this as well (or something like it) in mambo at boot, but it's pretty rare to hit. I'm trying to debug it. I'm guessing possibly an idle vs interrupt race. > [ 4255.151192] Sending NMI from CPU 5 to CPUs 0: > [ 4255.151246] NMI backtrace for cpu 0 > [ 4255.151287] CPU: 0 PID: 0 Comm:

Re: [PATCH] powerpc/kexec: Fix radix to hash kexec

Balbir Singh writes: > This patch fixes a crash seen while doing a kexec from > radix mode to hash mode. Key 0 is special in hash and > used in the RPN by default, we set the key values to 0 > today. In radix mode key 0 is used to control > supervisor<->user access. In

Re: [PATCH v11 07/10] powerpc/perf: PMU functions for Core IMC and hotplugging

On Thursday 29 June 2017 01:11 AM, Thomas Gleixner wrote: On Thu, 29 Jun 2017, Anju T Sudhakar wrote: +static void cleanup_all_core_imc_memory(struct imc_pmu *pmu_ptr) +{ + struct imc_mem_info *ptr; + + for (ptr = pmu_ptr->mem_info; ptr; ptr++) { + if (ptr->vbase[0])

Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host

On Thu, Jun 29, 2017 at 06:47:50PM +1000, Balbir Singh wrote: > On Thu, Jun 29, 2017 at 1:41 PM, Eryu Guan wrote: > > On Thu, Jun 29, 2017 at 03:16:10AM +1000, Balbir Singh wrote: > >> On Wed, Jun 28, 2017 at 6:32 PM, Eryu Guan wrote: > > >> Thanks for the

Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host

On Thu, Jun 29, 2017 at 1:41 PM, Eryu Guan wrote: > On Thu, Jun 29, 2017 at 03:16:10AM +1000, Balbir Singh wrote: >> On Wed, Jun 28, 2017 at 6:32 PM, Eryu Guan wrote: >> Thanks for the excellent bug report, I am a little lost on the stack >> trace, it shows a

  1   2   >