RE: [PATCH kernel] powerpc/powernv: Update comment about shifting IOV BAR

From: Benjamin Herrenschmidt > Sent: 14 September 2017 04:40 > On Thu, 2017-09-14 at 13:18 +1000, Alexey Kardashevskiy wrote: > > On 14/09/17 13:07, Benjamin Herrenschmidt wrote: > > > On Thu, 2017-09-14 at 12:45 +1000, Alexey Kardashevskiy wrote: > > > > On 31/08/17 13:34, Alexey Kardashevskiy

Re: [PATCH kernel] powerpc/powernv: Update comment about shifting IOV BAR

On Thu, 2017-09-14 at 09:27 +, David Laight wrote: > You can logically 'hotplug' PCI(e) on any system [1]. > > The 'problem' is that whatever enumerates the PCI(e) at system > powerup doesn't normally assign extra resources to bridges to allow > for devices that aren't present at boot time. >

Re: [PATCH v3 04/20] mm: VMA sequence count

On (09/14/17 10:58), Laurent Dufour wrote: [..] > That's right, but here this is the sequence counter mm->mm_seq, not the > vm_seq one. d'oh... you are right. -ss

Re: [PATCH v3 04/20] mm: VMA sequence count

On (09/14/17 11:15), Laurent Dufour wrote: > On 14/09/2017 11:11, Sergey Senozhatsky wrote: > > On (09/14/17 10:58), Laurent Dufour wrote: > > [..] > >> That's right, but here this is the sequence counter mm->mm_seq, not the > >> vm_seq one. > > > > d'oh... you are right. > > So I'm doubting

Re: [PATCH 4/5] powerpc/jprobes: Disable preemption when triggered through ftrace

On Thu, 14 Sep 2017 15:55:39 +0530 "Naveen N. Rao" wrote: > On 2017/09/13 05:05PM, Masami Hiramatsu wrote: > > On Thu, 14 Sep 2017 02:50:35 +0530 > > "Naveen N. Rao" wrote: > > > > > KPROBES_SANITY_TEST throws the below splat

Re: [PATCH v3 04/20] mm: VMA sequence count

Hi, On (09/14/17 09:55), Laurent Dufour wrote: [..] > > so if there are two CPUs, one doing write_seqcount() and the other one > > doing read_seqcount() then what can happen is something like this > > > > CPU0CPU1 > > > >

Re: [PATCH v3 04/20] mm: VMA sequence count

On 14/09/2017 10:13, Sergey Senozhatsky wrote: > Hi, > > On (09/14/17 09:55), Laurent Dufour wrote: > [..] >>> so if there are two CPUs, one doing write_seqcount() and the other one >>> doing read_seqcount() then what can happen is something like this >>> >>> CPU0

[PATCH] drivers: of: static DT reservations incorrectly added to dynamic list

There are two types of memory reservations firmware can ask the kernel to make in the device tree: static and dynamic. See Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt If you have greater than 16 entries in /reserved-memory (as we do on POWER9 systems) you would get this

Re: [RFC PATCH 2/2] powerpc/powernv: implement NMI IPIs with OPAL_SIGNAL_SYSTEM_RESET

On Wed, 13 Sep 2017 02:05:53 +1000 Nicholas Piggin wrote: > There are two complications. The first is that sreset from stop states > come in with SRR1 set to do a powersave wakeup, with an sreset reason > encoded. > > The second is that threads on the same core can't be

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

Le 14/09/2017 à 01:51, Rob Landley a écrit : From: Rob Landley Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move /dev/console open after devtmpfs mount. Add workaround for Debian bug that was copied by Ubuntu. Is that a bug only for Debian ? Why ? Why should a Debian

Re: [PATCH 02/25] powerpc: define an additional vma bit for protection keys.

On Thu, 2017-09-14 at 14:38 +1000, Balbir Singh wrote: > On Fri, 8 Sep 2017 15:44:50 -0700 > Ram Pai wrote: > > > powerpc needs an additional vma bit to support 32 keys. > > Till the additional vma bit lands in include/linux/mm.h > > we have to define it in powerpc

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

On Thu, 14 Sep 2017 12:08:07 +0530 "Naveen N. Rao" wrote: > On 2017/09/13 04:53PM, Masami Hiramatsu wrote: > > On Thu, 14 Sep 2017 02:50:33 +0530 > > "Naveen N. Rao" wrote: > > > > > Currently, we disable instruction emulation

Re: [PATCH 3/5] powerpc/kprobes: Fix warnings from __this_cpu_read() on preempt kernels

On Thursday 14 September 2017 02:50 AM, Naveen N. Rao wrote: 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

Re: [PATCH v3 04/20] mm: VMA sequence count

Hi, On 14/09/2017 02:31, Sergey Senozhatsky wrote: > Hi, > > On (09/13/17 18:56), Laurent Dufour wrote: >> Hi Sergey, >> >> On 13/09/2017 13:53, Sergey Senozhatsky wrote: >>> Hi, >>> >>> On (09/08/17 20:06), Laurent Dufour wrote: > [..] >>> ok, so what I got on my box is: >>> >>> vm_munmap() ->

Re: [PATCH 4/7] powerpc: Free up four 64K PTE bits in 64K backed HPTE pages

On Fri, 2017-09-08 at 15:44 -0700, Ram Pai wrote: > The second part of the PTE will hold > (H_PAGE_F_SECOND|H_PAGE_F_GIX) at bit 60,61,62,63. > NOTE: None of the bits in the secondary PTE were not used > by 64k-HPTE backed PTE. Have you measured the performance impact of this ? The second part of

Re: [PATCH v3 04/20] mm: VMA sequence count

On 14/09/2017 11:11, Sergey Senozhatsky wrote: > On (09/14/17 10:58), Laurent Dufour wrote: > [..] >> That's right, but here this is the sequence counter mm->mm_seq, not the >> vm_seq one. > > d'oh... you are right. So I'm doubting about the probability of a deadlock here, but I don't like to

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

On 2017/09/14 02:45AM, Masami Hiramatsu wrote: > On Thu, 14 Sep 2017 12:08:07 +0530 > "Naveen N. Rao" wrote: > > > On 2017/09/13 04:53PM, Masami Hiramatsu wrote: > > > On Thu, 14 Sep 2017 02:50:33 +0530 > > > "Naveen N. Rao"

Re: [PATCH 3/5] powerpc/kprobes: Fix warnings from __this_cpu_read() on preempt kernels

On Thu, 14 Sep 2017 12:17:20 +0530 "Naveen N. Rao" wrote: > On 2017/09/13 05:36PM, Masami Hiramatsu wrote: > > On Thu, 14 Sep 2017 02:50:34 +0530 > > "Naveen N. Rao" wrote: > > > > > Kamalesh pointed out that we are getting the

Re: [PATCH 4/5] powerpc/jprobes: Disable preemption when triggered through ftrace

On 2017/09/13 05:05PM, Masami Hiramatsu wrote: > On Thu, 14 Sep 2017 02:50:35 +0530 > "Naveen N. Rao" wrote: > > > KPROBES_SANITY_TEST throws the below splat when CONFIG_PREEMPT is > > enabled: > > > > [3.140410] Kprobe smoke test: started > > [3.149680]

Re: [v4 03/11] dt-bindings: soc/fsl: Update reserved memory binding for QBMan

On Thu, Aug 24, 2017 at 04:37:47PM -0400, Roy Pledge wrote: > Updates the QMan and BMan device tree bindings for reserved memory > nodes. This makes the reserved memory allocation compatible with > the shared-dma-pool usage. > > Signed-off-by: Roy Pledge > --- >

Re: [v4 07/11] soc/fsl/qbman: Rework portal mapping calls for ARM/PPC

On Thu, Aug 24, 2017 at 04:37:51PM -0400, Roy Pledge wrote: > diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c > index ff8998f..e31c843 100644 > --- a/drivers/soc/fsl/qbman/bman.c > +++ b/drivers/soc/fsl/qbman/bman.c > @@ -154,7 +154,7 @@ struct bm_mc { > }; > > struct

Re: [PATCH] net/ethernet/freescale: fix warning for ucc_geth

Hi Christophe, On Thu, 2017-09-14 at 15:24 +0200, Christophe LEROY wrote: > Hi, > > Le 14/09/2017 à 14:05, Valentin Longchamp a écrit : > > Simple printk format warning for the the ucc registers address. > > Did you test your patch with mpc83xx_defconfig ? No I only tested on a 85xx where I

Re: [v4 05/11] soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check

On Thu, Aug 24, 2017 at 04:37:49PM -0400, Roy Pledge wrote: > From: Claudiu Manoil > > Not relevant and arch dependent. Overkill for PPC. > > Signed-off-by: Claudiu Manoil > Signed-off-by: Roy Pledge > --- >

[PATCH] net/ethernet/freescale: fix warning for ucc_geth

Simple printk format warning for the the ucc registers address. Signed-off-by: Valentin Longchamp --- drivers/net/ethernet/freescale/ucc_geth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/ucc_geth.c

Re: [v4 01/11] soc/fsl/qbman: Use shared-dma-pool for BMan private memory allocations

On Thu, Aug 24, 2017 at 04:37:45PM -0400, Roy Pledge wrote: > --- a/drivers/soc/fsl/qbman/bman_ccsr.c > +++ b/drivers/soc/fsl/qbman/bman_ccsr.c [...] > @@ -201,6 +202,38 @@ static int fsl_bman_probe(struct platform_device *pdev) > return -ENODEV; > } > > + /* > + *

Re: Machine Check in P2010(e500v2)

On Sat, 2017-09-09 at 14:59 +0200, Joakim Tjernlund wrote: > On Sat, 2017-09-09 at 14:45 +0200, Joakim Tjernlund wrote: > > On Fri, 2017-09-08 at 22:27 +, Leo Li wrote: > > > > -Original Message- > > > > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com] > > > > Sent:

Re: [PATCH 02/25] powerpc: define an additional vma bit for protection keys.

On Thu, Sep 14, 2017 at 02:38:07PM +1000, Balbir Singh wrote: > On Fri, 8 Sep 2017 15:44:50 -0700 > Ram Pai wrote: > > > powerpc needs an additional vma bit to support 32 keys. > > Till the additional vma bit lands in include/linux/mm.h > > we have to define it in powerpc

Re: [PATCH 01/25] powerpc: initial pkey plumbing

On Thu, Sep 14, 2017 at 01:32:05PM +1000, Balbir Singh wrote: > On Fri, 8 Sep 2017 15:44:49 -0700 > Ram Pai wrote: > > > Basic plumbing to initialize the pkey system. > > Nothing is enabled yet. A later patch will enable it > > ones all the infrastructure is in

[PATCH 1/2] powerpc: Add workaround for P9 vector CI load issue

POWER9 DD2.1 and earlier has an issue where some cache inhibited vector load will return bad data. The workaround is two part, one firmware/microcode part triggers HMI interrupts when hitting such loads, the other part is this patch which then emulates the instructions in Linux. The affected

[PATCH v2] net/ethernet/freescale: fix warning for ucc_geth

uf_info.regs is resource_size_t i.e. phys_addr_t that can be either u32 or u64 according to CONFIG_PHYS_ADDR_T_64BIT. The printk format is thus adaptet to u64 and the regs value cast to u64 to take both u32 and u64 into account. Signed-off-by: Valentin Longchamp

Re: [PATCH] KVM: PPC: fix oops when checking KVM_CAP_PPC_HTM

Dang! The mail relay at OVH has blacklisted Paul's address :-\ : host smtp.samba.org[144.76.82.148] said: 550-blacklisted at zen.spamhaus.org 550 https://www.spamhaus.org/sbl/query/SBL370982 (in reply to RCPT TO command) Cc'ing Paul at ozlabs.org On Fri, 15 Sep 2017

[PATCH 2/2] powerpc: Handle MCE on POWER9 with only DSISR bit 33 set

On POWER9 DD2.1 and below, it's possible to get Machine Check Exception (MCE) where only DSISR bit 33 is set. This will result in the linux MCE handler seeing an unknown event, which triggers linux to crash. We change this by detecting unknown events in the MCE handler and marking them as handled

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

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 we take a HDSI. If we find the canary on a HDSI, we

Re: [PATCH] KVM: PPC: fix oops when checking KVM_CAP_PPC_HTM

On Thu, Sep 14, 2017 at 11:56:25PM +0200, Greg Kurz wrote: > The following program causes a kernel oops: > > #include > #include > #include > #include > #include > > main() > { > int fd = open("/dev/kvm", O_RDWR); > ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_PPC_HTM); > } > > This

Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow memory

On Thu, Sep 14, 2017 at 06:35:16PM -0400, Pavel Tatashin wrote: > To optimize the performance of struct page initialization, > vmemmap_populate() will no longer zero memory. > > We must explicitly zero the memory that is allocated by vmemmap_populate() > for kasan, as this memory does not go

Re: [PATCH v2] powerpc/tm: Flush TM only if CPU has TM feature

On Wed, 2017-09-13 at 22:13 -0400, Gustavo Romero wrote: > Commit cd63f3c ("powerpc/tm: Fix saving of TM SPRs in core dump") > added code to access TM SPRs in flush_tmregs_to_thread(). However > flush_tmregs_to_thread() does not check if TM feature is available on > CPU before trying to access TM

Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow memory

Hi Mark, Thank you for looking at this. We can't do this because page table is not set until cpu_replace_ttbr1() is called. So, we can't do memset() on this memory until then. Pasha

[PATCH 1/3] RTC: rv3029: fix vendor string

The vendor string for Microcrystal is microcrystal. Signed-off-by: Alexandre Belloni --- Documentation/devicetree/bindings/trivial-devices.txt | 2 +- drivers/rtc/rtc-rv3029c2.c| 2 ++ 2 files changed, 3 insertions(+), 1

[PATCH 2/3] ARM: dts: at91: usb_a9g20: fix rtc node

The rv3029 compatible is missing its vendor string, add it. Also fix the node name to be a proper generic name. Signed-off-by: Alexandre Belloni --- arch/arm/boot/dts/usb_a9g20_common.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[PATCH 3/3] powerpc/5200: dts: digsy_mtc.dts: fix rv3029 compatible

The proper compatible for rv3029 is microcrystal,rv3029. Signed-off-by: Alexandre Belloni --- arch/powerpc/boot/dts/digsy_mtc.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts

Re: [PATCH] net/ethernet/freescale: fix warning for ucc_geth

Hi, Le 14/09/2017 à 14:05, Valentin Longchamp a écrit : Simple printk format warning for the the ucc registers address. Did you test your patch with mpc83xx_defconfig ? I get a new warning with your patch: CC drivers/net/ethernet/freescale/ucc_geth.o In file included from

Re: [PATCH 4/7] powerpc: Free up four 64K PTE bits in 64K backed HPTE pages

On Thu, Sep 14, 2017 at 11:44:49AM +1000, Balbir Singh wrote: > On Fri, 8 Sep 2017 15:44:44 -0700 > Ram Pai wrote: > > > Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6 > > in the 64K backed HPTE pages. This along with the earlier > > patch will entirely free up

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

On Wed, Sep 13, 2017 at 06:51:25PM -0500, Rob Landley wrote: > From: Rob Landley > > Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move > /dev/console open after devtmpfs mount. > > Add workaround for Debian bug that was copied by Ubuntu. > > Signed-off-by: Rob Landley

Re: [v4 07/11] soc/fsl/qbman: Rework portal mapping calls for ARM/PPC

On 9/14/2017 10:00 AM, Catalin Marinas wrote: > On Thu, Aug 24, 2017 at 04:37:51PM -0400, Roy Pledge wrote: >> diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c >> index ff8998f..e31c843 100644 >> --- a/drivers/soc/fsl/qbman/bman.c >> +++ b/drivers/soc/fsl/qbman/bman.c >> @@

Re: [PATCH 7/7] powerpc: capture the PTE format changes in the dump pte report

On Thu, Sep 14, 2017 at 01:22:27PM +1000, Balbir Singh wrote: > On Fri, 8 Sep 2017 15:44:47 -0700 > Ram Pai wrote: > > > The H_PAGE_F_SECOND,H_PAGE_F_GIX are not in the 64K main-PTE. > > capture these changes in the dump pte report. > > > > Reviewed-by: Aneesh Kumar K.V

Re: [PATCH 5/7] powerpc: Swizzle around 4K PTE bits to free up bit 5 and bit 6

On Thu, Sep 14, 2017 at 11:48:34AM +1000, Balbir Singh wrote: > On Fri, 8 Sep 2017 15:44:45 -0700 > Ram Pai wrote: > > > We need PTE bits 3 ,4, 5, 6 and 57 to support protection-keys, > > because these are the bits we want to consolidate on across all > > configuration

Re: [PATCH 4/7] powerpc: Free up four 64K PTE bits in 64K backed HPTE pages

On Thu, Sep 14, 2017 at 10:54:08AM -0700, Ram Pai wrote: > On Thu, Sep 14, 2017 at 11:44:49AM +1000, Balbir Singh wrote: > > On Fri, 8 Sep 2017 15:44:44 -0700 > > Ram Pai wrote: > > > > > Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6 > > > in the 64K backed HPTE

Re: [v4 05/11] soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check

On 9/14/2017 9:49 AM, Catalin Marinas wrote: > On Thu, Aug 24, 2017 at 04:37:49PM -0400, Roy Pledge wrote: >> From: Claudiu Manoil >> >> Not relevant and arch dependent. Overkill for PPC. >> >> Signed-off-by: Claudiu Manoil >> Signed-off-by: Roy

[PATCH v8 08/11] mm: zero reserved and unavailable struct pages

Some memory is reserved but unavailable: not present in memblock.memory (because not backed by physical pages), but present in memblock.reserved. Such memory has backing struct pages, but they are not initialized by going through __init_single_page(). In some cases these struct pages are accessed

[PATCH v8 06/11] mm: zero struct pages during initialization

Add struct page zeroing as a part of initialization of other fields in __init_single_page(). This single thread performance collected on: Intel(R) Xeon(R) CPU E7-8895 v3 @ 2.60GHz with 1T of memory (268400646 pages in 8 nodes): BASEFIX sparse_init

[PATCH v8 02/11] sparc64/mm: setting fields in deferred pages

Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT), flags and other fields in "struct page"es are never changed prior to first initializing struct pages by going through __init_single_page(). With deferred struct page feature enabled there is a case where we set some fields

[PATCH v8 07/11] sparc64: optimized struct page zeroing

Add an optimized mm_zero_struct_page(), so struct page's are zeroed without calling memset(). We do eight to ten regular stores based on the size of struct page. Compiler optimizes out the conditions of switch() statement. SPARC-M6 with 15T of memory, single thread performance:

[PATCH v8 01/11] x86/mm: setting fields in deferred pages

Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT), flags and other fields in "struct page"es are never changed prior to first initializing struct pages by going through __init_single_page(). With deferred struct page feature enabled, however, we set fields in

[PATCH v8 04/11] sparc64: simplify vmemmap_populate

Remove duplicating code by using common functions vmemmap_pud_populate and vmemmap_pgd_populate. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob Picco

[PATCH v8 11/11] mm: stop zeroing memory during allocation in vmemmap

vmemmap_alloc_block() will no longer zero the block, so zero memory at its call sites for everything except struct pages. Struct page memory is zero'd by struct page initialization. Replace allocators in sprase-vmemmap to use the non-zeroing version. So, we will get the performance improvement

[PATCH v8 03/11] mm: deferred_init_memmap improvements

This patch fixes two issues in deferred_init_memmap = In deferred_init_memmap() where all deferred struct pages are initialized we have a check like this: if (page->flags) { VM_BUG_ON(page_zone(page) != zone); goto free_range; } This way we are checking if the current

[PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow memory

To optimize the performance of struct page initialization, vmemmap_populate() will no longer zero memory. We must explicitly zero the memory that is allocated by vmemmap_populate() for kasan, as this memory does not go through struct page initialization path. Signed-off-by: Pavel Tatashin

[PATCH v8 05/11] mm: defining memblock_virt_alloc_try_nid_raw

* A new variant of memblock_virt_alloc_* allocations: memblock_virt_alloc_try_nid_raw() - Does not zero the allocated memory - Does not panic if request cannot be satisfied * optimize early system hash allocations Clients can call alloc_large_system_hash() with flag: HASH_ZERO to specify

[PATCH v7 00/11] complete deferred page initialization

Changelog: v8 - v7 - Added Acked-by's from Dave Miller for SPARC changes - Fixed a minor compiling issue on tile architecture reported by kbuild v7 - v6 - Addressed comments from Michal Hocko - memblock_discard() patch was removed from this series and integrated separately - Fixed bug reported

[PATCH v8 00/11] complete deferred page initialization

Copy paste error, changing the subject for the header to v8 from v7. On 09/14/2017 06:35 PM, Pavel Tatashin wrote: Changelog: v8 - v7 - Added Acked-by's from Dave Miller for SPARC changes - Fixed a minor compiling issue on tile architecture reported by kbuild v7 - v6 - Addressed comments from

[PATCH] KVM: PPC: fix oops when checking KVM_CAP_PPC_HTM

The following program causes a kernel oops: #include #include #include #include #include main() { int fd = open("/dev/kvm", O_RDWR); ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_PPC_HTM); } This happens because when using the global KVM fd with KVM_CHECK_EXTENSION,

Re: [PATCH 1/5] powerpc/kprobes: Some cosmetic updates to try_to_emulate()

On Thursday 14 September 2017 02:50 AM, Naveen N. Rao wrote: 1. This is only used in kprobes.c, so make it static. 2. Remove the un-necessary (ret == 0) comparison in the else clause. Signed-off-by: Naveen N. Rao Reviewed-by: Kamalesh Babulal

Re: [RFC PATCH 2/2] powerpc/powernv: implement NMI IPIs with OPAL_SIGNAL_SYSTEM_RESET

On Thu, 14 Sep 2017 12:24:49 +1000 Benjamin Herrenschmidt wrote: > On Wed, 2017-09-13 at 23:13 +1000, Nicholas Piggin wrote: > > On Wed, 13 Sep 2017 02:05:53 +1000 > > Nicholas Piggin wrote: > > > > > There are two complications. The first is that

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

On 2017/09/13 04:53PM, Masami Hiramatsu wrote: > On Thu, 14 Sep 2017 02:50:33 +0530 > "Naveen N. Rao" wrote: > > > Currently, we disable instruction emulation if emulate_step() fails for > > any reason. However, such failures could be transient and specific to a

Re: [RFC PATCH 2/2] powerpc/powernv: implement NMI IPIs with OPAL_SIGNAL_SYSTEM_RESET

On Thu, 14 Sep 2017 04:32:28 PM Nicholas Piggin wrote: > On Thu, 14 Sep 2017 12:24:49 +1000 > Benjamin Herrenschmidt wrote: > > > On Wed, 2017-09-13 at 23:13 +1000, Nicholas Piggin wrote: > > > On Wed, 13 Sep 2017 02:05:53 +1000 > > > Nicholas Piggin

Re: [PATCH 3/5] powerpc/kprobes: Fix warnings from __this_cpu_read() on preempt kernels

On 2017/09/13 05:36PM, Masami Hiramatsu wrote: > On Thu, 14 Sep 2017 02:50:34 +0530 > "Naveen N. Rao" wrote: > > > Kamalesh pointed out that we are getting the below call traces with > > livepatched functions when we enable CONFIG_PREEMPT: > > > > [ 495.470721]