Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

Thomas Gleixner writes: > On Tue, 3 Oct 2017, Thomas Gleixner wrote: >> On Tue, 3 Oct 2017, Thomas Gleixner wrote: >> > On Tue, 3 Oct 2017, Michael Ellerman wrote: >> > > Hmm, I tried that patch, it makes the warning go away. But then I >> > > triggered a deliberate hard

[PATCH v2] powerpc: configs: Add Skiroot defconfig

This configuration is used by the OpenPower firmware for it's Linux-as-bootloader implementation. Also known as the Petitboot kernel, this configuration broke in 4.12 (CPU_HOTPLUG=n), so add it to the upstream tree in order to get better coverage. Signed-off-by: Joel Stanley ---

Re: [PATCH] mm/mmu_notifier: avoid double notification when it is useless

On Tue, Oct 03, 2017 at 05:43:47PM -0700, Nadav Amit wrote: > Jerome Glisse wrote: > > > On Wed, Oct 04, 2017 at 01:42:15AM +0200, Andrea Arcangeli wrote: > > > >> I'd like some more explanation about the inner working of "that new > >> user" as per comment above. > >> > >>

Re: [PATCH] mm/mmu_notifier: avoid double notification when it is useless

On Wed, Oct 04, 2017 at 01:42:15AM +0200, Andrea Arcangeli wrote: > Hello Jerome, > > On Fri, Sep 01, 2017 at 01:30:11PM -0400, Jerome Glisse wrote: > > +Case A is obvious you do not want to take the risk for the device to write > > to > > +a page that might now be use by some completely

Re: [PATCH] mm/mmu_notifier: avoid double notification when it is useless

Hello Jerome, On Fri, Sep 01, 2017 at 01:30:11PM -0400, Jerome Glisse wrote: > +Case A is obvious you do not want to take the risk for the device to write to > +a page that might now be use by some completely different task. used > +is true ven if the thread doing the page table update is

Re: [PATCH v9 12/12] mm: stop zeroing memory during allocation in vmemmap

Hi Michal, I decided not to merge these two patches, because in addition to sparc optimization move, we have this dependancies: mm: zero reserved and unavailable struct pages must be before mm: stop zeroing memory during allocation in vmemmap. Otherwise, we can end-up with struct pages

RE: [PATCH 02/11] x86: make dma_cache_sync a no-op

On Tue, 3 Oct 2017, David Laight wrote: > From: Christoph Hellwig > > Sent: 03 October 2017 11:43 > > x86 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't > > make any sense to do any work in dma_cache_sync given that it must be a > > no-op when dma_alloc_attrs returns

Re: [PATCH v2] powerpc: Blacklist GCC 5.4 6.1 and 6.2

On Mon, 13 Feb 2017 19:49:16 -0600 Segher Boessenkool wrote: > On Tue, Feb 14, 2017 at 11:25:43AM +1100, Cyril Bur wrote: > > > > At the time of writing GCC 5.4 is the most recent and is > > > > affected. GCC 6.3 contains the backported fix, has been tested > > > >

Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

On Tue, 3 Oct 2017, Thomas Gleixner wrote: > On Tue, 3 Oct 2017, Thomas Gleixner wrote: > > On Tue, 3 Oct 2017, Michael Ellerman wrote: > > > Hmm, I tried that patch, it makes the warning go away. But then I > > > triggered a deliberate hard lockup and got nothing. > > > > > > Then I went back to

[PATCH8/8] powerpc: Enable support of ibm,dynamic-memory-v2

Add required bits to the architecture vector to enable support of the ibm,dynamic-memory-v2 device tree property. Signed-off-by: Nathan Fontenot --- arch/powerpc/include/asm/firmware.h |3 ++- arch/powerpc/include/asm/prom.h |1 +

[PATCH7/8] powerpc/pseries: Add support for ibm, dynamic-memory-v2 property

The Power Hypervisor has introduced a new device tree format for the property describing the dynamic reconfiguration LMBs for a system. This new format condenses the size of the property, especially on large memory systems, to provide an entry per range of LMBs that possess the same flags and

[PATCH6/8] powerpc: Move of_drconf_cell struct to asm/drmem.h

Now that the powerpc code parses dynamic reconfiguration memory LMB information from the LMB array and not the device tree directly we can move the of_drconf_cell struct to drmem.h where it fits better. In addition, the struct is renamed to of_drconf_cell_v1 in anticipation of upcoming support

[PATCH5/8] powerpc/pseries: Update memory hotplug code to use drmem LMB array

Update the pseries memory hotplug code to use the newly added dynamic reconfiguration LMB array. Doing this is required for the upcoming support of the version 2 of the dynamic reconfiguration device tree property. In addition, making this change cleans up the code that parses the LMB information

[PATCH4/8] powerpc/numa: Update numa code use drmem LMB array

Update code in powerpc/numa.c to use the array of dynamic reconfiguration memory LMBs instead of parsing the device tree property directly. This allows for the removal of several helper routines and makes gathering LMB information easier. This patch also prepares the numa code for support of the

[PATCH3/8] powerpc/mm: Separate ibm, dynamic-memory data from DT format

We currently have code to parse the dynamic reconfiguration LMB information from the ibm,dynamic-meory device tree property in multiple locations (numa.c, prom.c, and pseries/hotplug-memory.c). In anticipation of adding support for a version 2 of the ibm,dynamic-memory property this patch aims to

[PATCH2/8] powerpc/numa: Look up device node in of_get_usable_memory()

Look up the device node for the usable memory property instead of having it passed in as a parameter. This changes precedes an update in which the calling routines for of_get_usable_memory() will not have the device node pointer to pass in. Signed-off-by: Nathan Fontenot

[PATCH1/8] powerpc/numa: Look up device node in of_get_assoc_arrays()

Look up the device node for the associativity array property instead of having it passed in as a parameter. This changes precedes an update in which the calling routines for of_get_assoc_arrays() will not have the device node pointer to pass in. Signed-off-by: Nathan Fontenot

[PATCH0/8] Support for ibm,dynamic-memory-v2 device tree property

This patch set provides a set of updates to de-couple the LMB information provided in the ibm,dynamic-memory device tree property from the device tree property format. The goal is to provide a data set of LMB information so that consumners of this data do not need to understand and provide

Re: [PATCH v2 4/5] powerpc: pseries: only store the device node basename in full_name

On Tue, Oct 3, 2017 at 4:26 AM, Michael Ellerman wrote: > Hi Rob, > > Unfortunately this one has a bug, which only showed up after some stress > testing. > > Rob Herring writes: >> With dependencies on full_name containing the entire device node path >>

Re: [PATCH] mm: remove unnecessary WARN_ONCE in page_vma_mapped_walk().

On Tue, Oct 03, 2017 at 10:26:06AM -0400, Zi Yan wrote: > From: Zi Yan > > A non present pmd entry can appear after pmd_lock is taken in > page_vma_mapped_walk(), even if THP migration is not enabled. > The WARN_ONCE is unnecessary. > > Fixes: 616b8371539a ("mm: thp:

Re: [PATCH 1/1] KVM: PPC: Book3S: Fix server always zero from kvmppc_xive_get_xive()

2017-10-02, David Gibson: > Paolo, > > Here's BenH's ack. Again, this is a pretty important fix for us, and > Paulus is away. Can you take this into the KVM tree please. Applied to kvm/master, thanks. (Turns out I'm not on any cc'd list, so the author date might be off.)

RE: [PATCH 02/11] x86: make dma_cache_sync a no-op

From: Christoph Hellwig > Sent: 03 October 2017 11:43 > x86 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't > make any sense to do any work in dma_cache_sync given that it must be a > no-op when dma_alloc_attrs returns coherent memory. I believe it is just about possible to

Re: [PATCH v9 03/12] mm: deferred_init_memmap improvements

Hi Michal, Are you OK, if I replace DEFERRED_FREE() macro with a function like this: /* * Helper for deferred_init_range, free the given range, and reset the * counters */ static inline unsigned long __def_free(unsigned long *nr_free, unsigned long

Re: [PATCH v9 12/12] mm: stop zeroing memory during allocation in vmemmap

On 10/03/2017 09:19 AM, Michal Hocko wrote: On Wed 20-09-17 16:17:14, Pavel Tatashin wrote: 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

Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages

On 10/03/2017 09:18 AM, Michal Hocko wrote: On Wed 20-09-17 16:17:10, Pavel Tatashin wrote: 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

Re: [PATCH v9 06/12] mm: zero struct pages during initialization

On 10/03/2017 09:08 AM, Michal Hocko wrote: On Wed 20-09-17 16:17:08, Pavel Tatashin wrote: 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

Re: [PATCH v9 04/12] sparc64: simplify vmemmap_populate

Acked-by: Michal Hocko Thank you, Pasha

Re: [PATCH v9 03/12] mm: deferred_init_memmap improvements

Hi Michal, Please be explicit that this is possible only because we discard memblock data later after 3010f876500f ("mm: discard memblock data later"). Also be more explicit how the new code works. OK I like how the resulting code is more compact and smaller. That was the goal :)

Re: [PATCH v9 02/12] sparc64/mm: setting fields in deferred pages

As you separated x86 and sparc patches doing essentially the same I assume David is going to take this patch? Correct, I noticed that usually platform specific changes are done in separate patches even if they are small. Dave already Acked this patch. So, I do not think it should be

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

Hi Mark, I considered using a new *populate() function for shadow without using vmemmap_populate(), but that makes things unnecessary complicated: vmemmap_populate() has builtin: 1. large page support 2. device memory support 3. node locality support 4. several config based variants on

Re: [PATCH v9 01/12] x86/mm: setting fields in deferred pages

Hi Michal, I hope I haven't missed anything but it looks good to me. Acked-by: Michal Hocko Thank you for your review. one nit below --- arch/x86/mm/init_64.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/init_64.c

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

Hi Pavel, On Wed, Sep 20, 2017 at 04:17:11PM -0400, Pavel Tatashin wrote: > During early boot, kasan uses vmemmap_populate() to establish its shadow > memory. But, that interface is intended for struct pages use. > > Because of the current project, vmemmap won't be zeroed during allocation, >

Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

On Tue, 3 Oct 2017, Thomas Gleixner wrote: > On Tue, 3 Oct 2017, Michael Ellerman wrote: > > Hmm, I tried that patch, it makes the warning go away. But then I > > triggered a deliberate hard lockup and got nothing. > > > > Then I went back to the existing code (in linux-next), and I still get > >

Re: [PATCH v9 12/12] mm: stop zeroing memory during allocation in vmemmap

On Wed 20-09-17 16:17:14, Pavel Tatashin wrote: > 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

Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages

On Wed 20-09-17 16:17:10, Pavel Tatashin wrote: > 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

Re: [PATCH v9 06/12] mm: zero struct pages during initialization

On Wed 20-09-17 16:17:08, Pavel Tatashin wrote: > 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): > >

Re: [PATCH 0/2] powerpc/xive: fix CPU hot unplug

Hello Michael, On 10/03/2017 01:23 PM, Michael Ellerman wrote: > Cédric Le Goater writes: > >> On 09/23/2017 10:26 AM, Cédric Le Goater wrote: >>> Hi, >>> >>> Here are a couple of small fixes to support CPU hot unplug. There are >>> still some issues to be investigated as, in

Re: [PATCH v9 04/12] sparc64: simplify vmemmap_populate

On Wed 20-09-17 16:17:06, Pavel Tatashin wrote: > 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

Re: [PATCH v9 03/12] mm: deferred_init_memmap improvements

On Wed 20-09-17 16:17:05, Pavel Tatashin wrote: > 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

Re: [PATCH v9 02/12] sparc64/mm: setting fields in deferred pages

On Wed 20-09-17 16:17:04, Pavel Tatashin wrote: > 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

Re: [PATCH v9 01/12] x86/mm: setting fields in deferred pages

On Wed 20-09-17 16:17:03, Pavel Tatashin wrote: > 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

[RFC PATCH] powerpc/perf: Add compact mode pmu support for powernv

Most of the power processor generation performance monitoring unit (PMU) driver code is bundled in the kernel and one of those is enabled/registered based on the oprofile_cpu_type check at the boot. But things get little tricky incase of "compact" mode boot. IBM POWER System Server based

Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

On Tue, 3 Oct 2017, Michael Ellerman wrote: > Thomas Gleixner writes: > >> The first call is new because previously watchdog_nmi_reconfigure() > >> wasn't called from softlockup_reconfigure_threads(). > > > > Hmm, don't you have the same problem with CPU hotplug or do you just

Re: refactor dma_cache_sync V2

On 03/10/17 11:43, Christoph Hellwig wrote: > The dma_cache_sync routines is used to flush caches for memory returned > by dma_alloc_attrs with the DMA_ATTR_NON_CONSISTENT flag (or previously > from dma_alloc_noncoherent), but the requirements for it seems to be > frequently misunderstood.

Re: [PATCH 07/11] powerpc: make dma_cache_sync a no-op

On Tue, Oct 03, 2017 at 01:24:57PM +0200, Christophe LEROY wrote: >> powerpc does not implement DMA_ATTR_NON_CONSISTENT allocations, so it >> doesn't make any sense to do any work in dma_cache_sync given that it >> must be a no-op when dma_alloc_attrs returns coherent memory. > What about

Re: [PATCH 07/11] powerpc: make dma_cache_sync a no-op

On 03/10/17 12:24, Christophe LEROY wrote: > > > Le 03/10/2017 à 12:43, Christoph Hellwig a écrit : >> powerpc does not implement DMA_ATTR_NON_CONSISTENT allocations, so it >> doesn't make any sense to do any work in dma_cache_sync given that it >> must be a no-op when dma_alloc_attrs returns

Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

Thomas Gleixner writes: > On Tue, 3 Oct 2017, Michael Ellerman wrote: >> Hi Thomas, >> Unfortunately this is hitting the WARN_ON in start_wd_cpu() on powerpc >> because we're calling it multiple times for the boot CPU. >> >> The first call is via: >> >>

Re: [PATCH 07/11] powerpc: make dma_cache_sync a no-op

Le 03/10/2017 à 12:43, Christoph Hellwig a écrit : powerpc does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't make any sense to do any work in dma_cache_sync given that it must be a no-op when dma_alloc_attrs returns coherent memory. What about

Re: [PATCH 0/2] powerpc/xive: fix CPU hot unplug

Cédric Le Goater writes: > On 09/23/2017 10:26 AM, Cédric Le Goater wrote: >> Hi, >> >> Here are a couple of small fixes to support CPU hot unplug. There are >> still some issues to be investigated as, in some occasions, after a >> couple of plug and unplug, the cpu which was

[PATCH 2/2] powerpc/perf: Fix unit_sel/cache_sel checks

Raw event code has couple of fields "unit" and "cache" in it to capture the "unit" to monitor for a given pmcxsel and cache reload qualifier to program in MMCR1. isa207_get_constraint() refers "unit" field to update the MMCRC L2/L3 Event bus control fields with "cache" bits of the raw event code.

[PATCH 1/2] powerpc/perf: Cleanup cache_sel bits comment

Update the raw event code comment in power9-pmu.c with respect to "cache" bits, since power9 MMCRC does not support these. Signed-off-by: Madhavan Srinivasan --- arch/powerpc/perf/power9-pmu.c | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff

Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

On Tue, 3 Oct 2017, Nicholas Piggin wrote: > On Tue, 3 Oct 2017 09:04:03 +0200 (CEST) > Thomas Gleixner wrote: > > > On Tue, 3 Oct 2017, Thomas Gleixner wrote: > > > On Tue, 3 Oct 2017, Michael Ellerman wrote: > > > > Hi Thomas, > > > > Unfortunately this is hitting the

[PATCH 11/11] dma-mapping: turn dma_cache_sync into a dma_map_ops method

After we removed all the dead wood it turns out only two architectures actually implement dma_cache_sync as a real op: mips and parisc. Add a cache_sync method to struct dma_map_ops and implement it for the mips defualt DMA ops, and the parisc pa11 ops. Note that arm, arc and openrisc support

[PATCH 10/11] sh: make dma_cache_sync a no-op

sh does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't make any sense to do any work in dma_cache_sync given that it must be a no-op when dma_alloc_attrs returns coherent memory. On the other hand sh uses dma_cache_sync internally in the dma_ops implementation and for the maple

[PATCH 09/11] xtensa: make dma_cache_sync a no-op

xtensa does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't make any sense to do any work in dma_cache_sync given that it must be a no-op when dma_alloc_attrs returns coherent memory. Signed-off-by: Christoph Hellwig --- arch/xtensa/include/asm/dma-mapping.h | 6

[PATCH 08/11] unicore32: make dma_cache_sync a no-op

unicore32 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't make any sense to do any work in dma_cache_sync given that it must be a no-op when dma_alloc_attrs returns coherent memory. Signed-off-by: Christoph Hellwig --- arch/unicore32/include/asm/cacheflush.h

[PATCH 07/11] powerpc: make dma_cache_sync a no-op

powerpc does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't make any sense to do any work in dma_cache_sync given that it must be a no-op when dma_alloc_attrs returns coherent memory. Signed-off-by: Christoph Hellwig --- arch/powerpc/include/asm/dma-mapping.h | 2

[PATCH 06/11] mn10300: make dma_cache_sync a no-op

mn10300 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't make any sense to do any work in dma_cache_sync given that it must be a no-op when dma_alloc_attrs returns coherent memory. Signed-off-by: Christoph Hellwig --- arch/mn10300/include/asm/dma-mapping.h | 4

[PATCH 05/11] microblaze: make dma_cache_sync a no-op

microblaze does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't make any sense to do any work in dma_cache_sync given that it must be a no-op when dma_alloc_attrs returns coherent memory. This also allows moving __dma_sync out of the microblaze asm/dma-mapping.h and thus greatly

[PATCH 04/11] ia64: make dma_cache_sync a no-op

ia64 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't make any sense to do any work in dma_cache_sync given that it must be a no-op when dma_alloc_attrs returns coherent memory. Signed-off-by: Christoph Hellwig --- arch/ia64/include/asm/dma-mapping.h | 5 -

[PATCH 03/11] frv: make dma_cache_sync a no-op

frv does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't make any sense to do any work in dma_cache_sync given that it must be a no-op when dma_alloc_attrs returns coherent memory. Signed-off-by: Christoph Hellwig --- arch/frv/include/asm/dma-mapping.h | 1 - 1

[PATCH 01/11] floppy: consolidate the dummy fd_cacheflush definition

Only mips defines this helper, so remove all the other arch definitions. Signed-off-by: Christoph Hellwig --- arch/alpha/include/asm/floppy.h| 2 -- arch/powerpc/include/asm/floppy.h | 2 -- arch/sparc/include/asm/floppy_32.h | 1 - arch/sparc/include/asm/floppy_64.h | 1 -

[PATCH 02/11] x86: make dma_cache_sync a no-op

x86 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't make any sense to do any work in dma_cache_sync given that it must be a no-op when dma_alloc_attrs returns coherent memory. Signed-off-by: Christoph Hellwig Reviewed-by: Thomas Gleixner

refactor dma_cache_sync V2

The dma_cache_sync routines is used to flush caches for memory returned by dma_alloc_attrs with the DMA_ATTR_NON_CONSISTENT flag (or previously from dma_alloc_noncoherent), but the requirements for it seems to be frequently misunderstood. dma_cache_sync is documented to be a no-op for allocations

Re: [linux-next][Oops] memory hot-unplug results fault instruction address at /include/linux/list.h:104

On Wed, 2017-09-20 at 12:54 -0700, Kees Cook wrote: > On Wed, Sep 20, 2017 at 12:40 AM, Abdul Haleem > wrote: > > On Tue, 2017-09-12 at 12:11 +0530, abdul wrote: > >> Hi, > >> > >> Memory hot-unplug on PowerVM LPAR running next-20170911 results in > >> Faulting

Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

On Tue, 3 Oct 2017 09:04:03 +0200 (CEST) Thomas Gleixner wrote: > On Tue, 3 Oct 2017, Thomas Gleixner wrote: > > On Tue, 3 Oct 2017, Michael Ellerman wrote: > > > Hi Thomas, > > > Unfortunately this is hitting the WARN_ON in start_wd_cpu() on powerpc > > > because we're

Re: [PATCH] kernel/module_64.c: Add REL24 relocation support of livepatch symbols

Hi Kamalesh, On 2017/10/03 05:36AM, Kamalesh Babulal wrote: > With commit 425595a7fc20 ("livepatch: reuse module loader code to > write relocations") livepatch uses module loader to write relocations > of livepatch symbols, instead of managing them by arch-dependent > klp_write_module_reloc()

Re: [PATCH v2 4/5] powerpc: pseries: only store the device node basename in full_name

Hi Rob, Unfortunately this one has a bug, which only showed up after some stress testing. Rob Herring writes: > With dependencies on full_name containing the entire device node path > removed, stop storing the full_name in nodes created by > dlpar_configure_connector() and

Re: [linux-next] [bisected a4615d11] Memory DLPAR triggers WARN_ONCE() in mm/page_vma_mapped.c

On Fri, 2017-09-29 at 10:07 -0400, Zi Yan wrote: > Hi Abdul, > > I just want to follow up with this. > > Did you have a chance to test my patch? Does it fix your original problem? Yes I did test the patch. it fixes the warning. Reported-and-tested-by: Abdul Haleem

Re: [PATCH 4.4] cxl: Fix driver use count

On Wed, Sep 27, 2017 at 10:43:17AM +1000, Andrew Donnellan wrote: > From: Frederic Barrat > > commit 197267d0356004a31c4d6b6336598f5dff3301e1 upstream. > > cxl keeps a driver use count, which is used with the hash memory model > on p8 to know when to upgrade local

Re: [PATCH v3] powerpc: fix compile error on 64K pages on 40x, 44x

Le 01/10/2017 à 16:33, Christian Lamparter a écrit : The mmu context on the 40x, 44x does not define pte_frag entry. This causes gcc abort the compilation due to: setup-common.c: In function ‘setup_arch’: setup-common.c:908: error: ‘mm_context_t’ has no ‘pte_frag’ This patch fixes the issue

Re: [PATCH 0/2] powerpc/xive: fix CPU hot unplug

On Tue, 2017-10-03 at 17:58 +1100, David Gibson wrote: > > Ok.. why do you think this isn't of use? I'm pretty sure this is > necessary for the TCG case, since MSR is checked in cpu_has_work(), > which could otherwise wake up the "dead" cpu. Ony if it's not in a PM state, in that case we check

Re: [PATCH v3 00/20] Speculative page faults

On 03/10/2017 03:27, Michael Ellerman wrote: > Laurent Dufour writes: > >> Hi Andrew, >> >> On 28/09/2017 22:38, Andrew Morton wrote: >>> On Thu, 28 Sep 2017 14:29:02 +0200 Laurent Dufour >>> wrote: >>> > Laurent's [0/n] provides some

Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

On Tue, 3 Oct 2017, Thomas Gleixner wrote: > On Tue, 3 Oct 2017, Michael Ellerman wrote: > > Hi Thomas, > > Unfortunately this is hitting the WARN_ON in start_wd_cpu() on powerpc > > because we're calling it multiple times for the boot CPU. > > > > The first call is via: > > > >

Re: [PATCH 0/2] powerpc/xive: fix CPU hot unplug

On Tue, Oct 03, 2017 at 08:24:07AM +0200, Cédric Le Goater wrote: > On 10/03/2017 05:36 AM, David Gibson wrote: > > On Mon, Oct 02, 2017 at 06:27:20PM +0200, Cédric Le Goater wrote: > >> On 09/23/2017 10:26 AM, Cédric Le Goater wrote: > >>> Hi, > >>> > >>> Here are a couple of small fixes to

Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

On Tue, 3 Oct 2017, Michael Ellerman wrote: > Hi Thomas, > Unfortunately this is hitting the WARN_ON in start_wd_cpu() on powerpc > because we're calling it multiple times for the boot CPU. > > The first call is via: > > start_wd_on_cpu+0x80/0x2f0 > watchdog_nmi_reconfigure+0x124/0x170 >

Re: [PATCH 0/2] powerpc/xive: fix CPU hot unplug

On 10/03/2017 05:36 AM, David Gibson wrote: > On Mon, Oct 02, 2017 at 06:27:20PM +0200, Cédric Le Goater wrote: >> On 09/23/2017 10:26 AM, Cédric Le Goater wrote: >>> Hi, >>> >>> Here are a couple of small fixes to support CPU hot unplug. There are >>> still some issues to be investigated as, in