Re: [PATCH v1 1/3] powerpc/kernel: Split up pci_bus_add_device

On 9/21/17 3:43 PM, Bjorn Helgaas wrote: On Mon, Sep 18, 2017 at 02:26:49PM -0500, Bryant G. Ly wrote: When enabling SR-IOV one might want to have their own version of starting device drivers for the VFs. This patch allows for SR-IOV callers to use pci_bus_add_virtfn_device instead of generic

RE: [RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

Tested patch series on ia64 successfully. Tested-by: Tony Luck After this goes upstream, you should submit a patch to get rid of all uses of %pF (70 instances in 35 files) and %pf (63 in 34) Perhaps break the patch by top-level directory (e.g. get all the %pF and %pF in

Re: [PATCH 4/6] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

On Fri, Sep 22, 2017 at 04:00:19PM +1000, Balbir Singh wrote: > On Fri, 15 Sep 2017 18:21:08 -0700 > Ram Pai wrote: > > > From: Thiago Jung Bauermann > > > > Expose useful information for programs using memory protection keys. > > Provide

Re: [PATCH] cxl: Fix memory page not handled

Le 22/09/2017 à 15:08, Christophe Lombard a écrit : The a in-kernel 'library' API can be called by drivers to help "the in-kernel library" interaction with an IBM XSL on a POWER9 system. The cxllib_handle_fault() API is used to handle memory fault. All memory pages of the specified

[PATCH v3 2/2] pseries/eeh: Add Pseries pcibios_bus_add_device

This patch adds the machine dependent call for pcibios_bus_add_device, since the previous patch separated the calls out between the PowerNV and PowerVM. The difference here is that for the PowerVM environment we do not want match_driver set because in this environment we do not want the VF device

[PATCH v3 0/2] Prepartion for SR-IOV PowerVM Enablement

This patch series is to prepare for enabling SR-IOV on pseries. It separates the calls to be machine dependent and does not change any current functionality. The patch linked below which is currently in review is a dependency: https://patchwork.kernel.org/patch/9882915/ v1 - Initial patch v2 -

[PATCH v3 1/2] powerpc/kernel: Separate SR-IOV Calls

SR-IOV can now be enabled in PowerNV platforms and Pseries platforms. Therefore, the appropriate calls were moved to machine dependent code instead of definition at compile time. Signed-off-by: Bryant G. Ly Signed-off-by: Juan J. Alvarez ---

Re: [PATCH] perf tools: allow overriding MAX_NR_CPUS at compile time

Em Fri, Sep 22, 2017 at 01:20:43PM +0200, Christophe Leroy escreveu: > After update of kernel, perf tool doesn't run anymore on my > 32MB RAM powerpc board, but still runs on a 128MB RAM board: > > ~# strace perf > execve("/usr/sbin/perf", ["perf"], [/* 12 vars */]) = -1 ENOMEM (Cannot >

Re: [PATCH v2 2/3] powerpc/64: enhance memcmp() with VMX instruction for long bytes comparision

On Thu, 2017-09-21 at 07:34 +0800, wei.guo.si...@gmail.com wrote: > From: Simon Guo > > This patch add VMX primitives to do memcmp() in case the compare size > exceeds 4K bytes. > Hi Simon, Sorry I didn't see this sooner, I've actually been working on a kernel version

[PATCH v2 2/2] pseries/eeh: Add Pseries pcibios_bus_add_device

This patch adds the machine dependent call for pcibios_bus_add_device, since the previous patch separated the calls out between the PowerNV and PowerVM. The difference here is that for the PowerVM environment we do not want match_driver set because in this environment we do not want the VF device

[PATCH v2 1/2] powerpc/kernel: Separate SR-IOV Calls

SR-IOV can now be enabled in PowerNV platforms and Pseries platforms. Therefore, the appropriate calls were moved to machine dependent code instead of definition at compile time. Signed-off-by: Bryant G. Ly Signed-off-by: Juan J. Alvarez ---

[PATCH v2 0/2] Prepartion for SR-IOV PowerVM Enablement

This patch series is to prepare for enabling SR-IOV on pseries. It separates the calls to be machine dependent and does not change any current functionality. This patch which is currently in review is a dependency: https://patchwork.kernel.org/patch/9882915/ Bryant G. Ly (2): powerpc/kernel:

[PATCH] cxl: Fix memory page not handled

The a in-kernel 'library' API can be called by drivers to help interaction with an IBM XSL on a POWER9 system. The cxllib_handle_fault() API is used to handle memory fault. All memory pages of the specified buffer have to be handled but the last page is never touched, and the address the adapter

Re: [linux-next][DLPAR CPU][Oops] Bad kernel stack pointer

nf_reject_ipv4 tun bridge stp llc kvm_pr kvm rpadlpar_io rpaphp ebtable_filter ebtables ip6table_filter ip6_tables dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag af_packet_diag iptable_filter netlink_diag sg nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc ip_tables

[GIT PULL] Please pull powerpc/linux.git powerpc-4.14-3 tag

Hi Linus, Please pull some more powerpc fixes for 4.14. It turns out our single-fix pull from last week was too good to be true. I missed a few fixes in that pull that had already come in because I was on leave, but also we hadn't found the bugs yet. So this week it's a bit bigger, though not

Re: [linux-next][DLPAR CPU][Oops] Bad kernel stack pointer

Abdul Haleem writes: > On Wed, 2017-09-20 at 21:42 +1000, Michael Ellerman wrote: >> Abdul Haleem writes: >> >> > Hi, >> > >> > Dynamic CPU remove operation resulted in Kernel Panic on today's >> > next-20170915 kernel. >> > >> >

Re: [mainline][DLPAR][Oops] OF: ERROR: Bad of_node_put() on /cpus

Tyrel Datwyler writes: > On 09/21/2017 02:57 AM, Michael Ellerman wrote: >> Tyrel Datwyler writes: >>> On 09/20/2017 04:39 AM, Michael Ellerman wrote: Rob Herring writes: > > > Testing a fix, will report

[PATCH 3/3] powerpc: powermac: use setup_timer() helper.

Use setup_timer function instead of initializing timer with the function and data fields. Signed-off-by: Allen Pais --- arch/powerpc/platforms/powermac/low_i2c.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[PATCH 2/3] powerpc: use setup_timer() helper.

Use setup_timer function instead of initializing timer with the function and data fields. Signed-off-by: Allen Pais --- arch/powerpc/kernel/tau_6xx.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/tau_6xx.c

[PATCH 1/3] powerpc: oprofile: use setup_timer() helper.

Use setup_timer function instead of initializing timer with the function and data fields. Signed-off-by: Allen Pais --- arch/powerpc/oprofile/op_model_cell.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git

[PATCH 0/3] use setup_timer() helper function.

This series uses setup_timer() helper function. The series addresses the files under arch/powerpc/*. Allen Pais (3): powerpc: oprofile: use setup_timer() helper. powerpc: use setup_timer() helper. powerpc: powermac: use setup_timer() helper. arch/powerpc/kernel/tau_6xx.c | 3

[PATCH] perf tools: allow overriding MAX_NR_CPUS at compile time

After update of kernel, perf tool doesn't run anymore on my 32MB RAM powerpc board, but still runs on a 128MB RAM board: ~# strace perf execve("/usr/sbin/perf", ["perf"], [/* 12 vars */]) = -1 ENOMEM (Cannot allocate memory) --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +++

Re: [PATCH v3] powerpc: Handle MCE on POWER9 with only DSISR bit 33 set

On Fri, Sep 22, 2017 at 1:32 PM, Michael Neuling wrote: > On POWER9 DD2.1 and below, it's possible for a paste instruction to > cause a Machine Check Exception (MCE) where only DSISR bit 33 is > set. This will result in the MCE handler seeing an unknown event, > which triggers

[PATCH] KVM: PPC: Book3S PR: only call slbmte for valid SLB entries

Userland passes an array of 64 SLB descriptors to KVM_SET_SREGS, some of which are valid (ie, SLB_ESID_V is set) and the rest are likely all-zeroes (with QEMU at least). Each of them is then passed to kvmppc_mmu_book3s_64_slbmte(), which assumes to find the SLB index in the 3 lower bits of its rb

Re: [PATCH] KVM: PPC: Book3S HV: Check for updated HDSISR on P9 HDSI exception

On 22/09/2017 12:30, David Gibson wrote: > On Fri, Sep 22, 2017 at 10:46:36AM +0200, Paolo Bonzini wrote: >> On 15/09/2017 07:26, Michael Neuling wrote: >>> On POWER9 DD2.1 and below, sometimes on a Hypervisor Data Storage >>> Interrupt (HDSI) the HDSISR is not be updated at all. >>> >>> To work

Re: [PATCH] KVM: PPC: Book3S HV: Check for updated HDSISR on P9 HDSI exception

On Fri, Sep 22, 2017 at 10:46:36AM +0200, Paolo Bonzini wrote: > On 15/09/2017 07:26, Michael Neuling wrote: > > On POWER9 DD2.1 and below, sometimes on a Hypervisor Data Storage > > Interrupt (HDSI) the HDSISR is not be updated at all. > > > > To work around this we put a canary value into the

Re: [linux-next][EXT4][Oops]kernel panics when running fsfuzzer

On Wed, 2017-09-20 at 16:44 +1000, Michael Ellerman wrote: > Abdul Haleem writes: > > > Hi, > > > > next kernel panics when running fsfuzzer test on ext4 file system. > > > > Machine Type: Power 7 PowerVM LPAR > > kernel : 4.13.0-next-20170915 > > config : attached >

Re: [PATCH 00/11] crypto: gcm - add GCM IV size constant

On Tue, Aug 22, 2017 at 10:08:07AM +0200, Corentin Labbe wrote: > Many GCM users use directly GCM IV size instead of using some constant. > > This patch add all IV size constant used by GCM and convert drivers for using > them.. > > Corentin Labbe (11): > crypto: gcm - add GCM iv size

Re: [PATCH] crypto: nx: 842: constify vio_device_id

On Thu, Aug 17, 2017 at 06:44:11PM +0530, Arvind Yadav wrote: > vio_device_id are not supposed to change at runtime. All functions > working with vio_device_id provided by work with > const vio_device_id. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav

Re: [PATCH] hwrng: pseries: constify vio_device_id

On Thu, Aug 17, 2017 at 11:06:23PM +0530, Arvind Yadav wrote: > vio_device_id are not supposed to change at runtime. All functions > working with vio_device_id provided by work with > const vio_device_id. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav

Re: [PATCH] crypto: nx: constify vio_device_id

On Thu, Aug 17, 2017 at 06:44:10PM +0530, Arvind Yadav wrote: > vio_device_id are not supposed to change at runtime. All functions > working with vio_device_id provided by work with > const vio_device_id. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav

Re: [1/2] powerpc/pseries: fix "OF: ERROR: Bad of_node_put() on /cpus" during DLPAR

On Fri, 2017-09-22 at 11:03 +1000, Michael Ellerman wrote: > On Wed, 2017-09-20 at 21:02:51 UTC, Tyrel Datwyler wrote: > > Commit 215ee763f8cb ("powerpc: pseries: remove dlpar_attach_node dependency > > on > > full path") reworked dlpar_attach_node() to no longer look up the parent > > node

Re: [linux-next][DLPAR CPU][Oops] Bad kernel stack pointer

On Wed, 2017-09-20 at 21:42 +1000, Michael Ellerman wrote: > Abdul Haleem writes: > > > Hi, > > > > Dynamic CPU remove operation resulted in Kernel Panic on today's > > next-20170915 kernel. > > > > Machine Type: Power 7 PowerVM LPAR > > Kernel : 4.13.0-next-20170915

[PATCH v2 6/6] powerpc/jprobes: Validate break handler invocation as being due to a jprobe_return()

Fix a circa 2005 FIXME by implementing a check to ensure that we actually got into the jprobe break handler() due to the trap in jprobe_return(). Acked-by: Masami Hiramatsu Signed-off-by: Naveen N. Rao --- arch/powerpc/kernel/kprobes.c | 20

[PATCH v2 5/6] powerpc/jprobes: Disable preemption when triggered through ftrace

KPROBES_SANITY_TEST throws the below splat when CONFIG_PREEMPT is enabled: [3.140410] Kprobe smoke test: started [3.149680] DEBUG_LOCKS_WARN_ON(val > preempt_count()) [3.149684] [ cut here ] [3.149695] WARNING: CPU: 19 PID: 1 at kernel/sched/core.c:3094

[PATCH v2 3/6] powerpc/kprobes: Clean up jprobe detection in livepatch handler

In commit c05b8c4474c03 ("powerpc/kprobes: Skip livepatch_handler() for jprobes"), we added a helper is_current_kprobe_addr() to help detect if the modified regs->nip was due to a jprobe or livepatch. Masami felt that the function name was not quite clear. To that end, this patch renames

[PATCH v2 4/6] powerpc/kprobes: Fix warnings from __this_cpu_read() on preempt kernels

Kamalesh pointed out that we are getting the below call traces with livepatched functions when we enable CONFIG_PREEMPT: [ 495.470721] BUG: using __this_cpu_read() in preemptible [] code: cat/8394 [ 495.471167] caller is is_current_kprobe_addr+0x30/0x90 [ 495.471171] CPU: 4 PID: 8394

[PATCH v2 1/6] powerpc/kprobes: Some cosmetic updates to try_to_emulate()

1. This is only used in kprobes.c, so make it static. 2. Remove the un-necessary (ret == 0) comparison in the else clause. Reviewed-by: Masami Hiramatsu Reviewed-by: Kamalesh Babulal Signed-off-by: Naveen N. Rao

[PATCH v2 2/6] powerpc/kprobes: Do not suppress instruction emulation if a single run failed

Currently, we disable instruction emulation if emulate_step() fails for any reason. However, such failures could be transient and specific to a particular run. Instead, only disable instruction emulation if we have never been able to emulate this. If we had emulated this instruction successfully

[PATCH v2 0/6] powerpc/kprobes: More fixes

This is v2 of the patches posted at: http://lkml.kernel.org/r/2bc413d679c563d3ee338c318066777318577ab2.1505336870.git.naveen.n@linux.vnet.ibm.com Changes: - No changes in patch 1, 4 and 5. - Comment updated in patch 2, as suggested by Masami. - Patch 3 has changes to explicitly call out

Re: [PATCH] KVM: PPC: Book3S HV: Check for updated HDSISR on P9 HDSI exception

On 15/09/2017 07:26, Michael Neuling wrote: > On POWER9 DD2.1 and below, sometimes on a Hypervisor Data Storage > Interrupt (HDSI) the HDSISR is not be updated at all. > > To work around this we put a canary value into the HDSISR before > returning to a guest and then check for this canary when

Re: [RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

On (09/22/17 11:04), Santosh Sivaraj wrote: [..] > > *** A BIG NOTE *** > > I don't own ia64/ppc64/parisc64 hardware, so the patches are not > > tested. Sorry about that! > > Tested patch series on ppc64 sucessfully. > > You may add tested by to the series. > > Tested-by:

Re: [PATCH v2 2/3] powerpc/64: enhance memcmp() with VMX instruction for long bytes comparision

Hi, On Thu, Sep 21, 2017 at 07:34:39AM +0800, wei.guo.si...@gmail.com wrote: > From: Simon Guo > > This patch add VMX primitives to do memcmp() in case the compare size > exceeds 4K bytes. > > Test result with following test program(replace the "^>" with ""): > -- I

Re: [PATCH 1/6] mm: introduce an additional vma bit for powerpc pkey

On Fri, 15 Sep 2017 18:21:05 -0700 Ram Pai wrote: > Currently only 4bits are allocated in the vma flags to hold 16 > keys. This is sufficient for x86. PowerPC supports 32 keys, > which needs 5bits. This patch allocates an additional bit. > > Signed-off-by: Ram Pai

Re: [PATCH 3/6] mm: display pkey in smaps if arch_pkeys_enabled() is true

On Fri, 15 Sep 2017 18:21:07 -0700 Ram Pai wrote: > +#ifdef CONFIG_ARCH_HAS_PKEYS > + if (arch_pkeys_enabled()) Sorry, I missed this bit in my previous review the patch makes sense > + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma)); > +#endif > +

Re: [PATCH 3/6] mm: display pkey in smaps if arch_pkeys_enabled() is true

On Fri, 15 Sep 2017 18:21:07 -0700 Ram Pai wrote: > Currently the architecture specific code is expected to > display the protection keys in smap for a given vma. > This can lead to redundant code and possibly to divergent > formats in which the key gets displayed. >

Re: [PATCH 4/6] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

On Fri, 15 Sep 2017 18:21:08 -0700 Ram Pai wrote: > From: Thiago Jung Bauermann > > Expose useful information for programs using memory protection keys. > Provide implementation for powerpc and x86. > > On a powerpc system with pkeys support,