Re: [PATCH v2 3/3] powerpc/powernv: Always stop secondaries before reboot/shutdown

On 04/01/2018 04:06 PM, Nicholas Piggin wrote: Currently powernv reboot and shutdown requests just leave secondaries to do their own things. This is undesirable because they can trigger any number of watchdogs while waiting for reboot, but also we don't know what else they might be doing -- they

Re: [PATCH 4/5] powerpc/pm: add sleep and deep sleep on QorIQ SoCs

Hi Ran, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on powerpc/next] [also build test WARNING on v4.16 next-20180329] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

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

I think CMA has protected us from hot-remove, so this patch is not necessary. Regards, Pingfan On Mon, Apr 2, 2018 at 2:30 PM, Mahesh J Salgaonkar wrote: > From: Mahesh Salgaonkar > > For fadump to work successfully there should not be any

Re: [PATCH v2 1/3] powerpc: use NMI IPI for smp_send_stop

On Tue, 3 Apr 2018 10:13:26 +1000 Balbir Singh wrote: > On Sun, 1 Apr 2018 20:36:13 +1000 > Nicholas Piggin wrote: > > > Use the NMI IPI rather than smp_call_function for smp_send_stop. > > Have stopped CPUs hard disable interrupts rather than just

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

> On 29 Mar 2018, at 00:07, Luck, Tony wrote: > >> The default limit of only 65536 VMAs will also quickly come into play >> if consecutive anon mmaps don't get merged. Of course this can be >> raised, but it has significant resource and performance (fork) costs. > > Could

Re: [PATCH v2 1/3] powerpc: use NMI IPI for smp_send_stop

On Sun, 1 Apr 2018 20:36:13 +1000 Nicholas Piggin wrote: > Use the NMI IPI rather than smp_call_function for smp_send_stop. > Have stopped CPUs hard disable interrupts rather than just soft > disable. > > This function is used in crash/panic/shutdown paths to bring other >

Re: [PATCH v9 17/24] mm: Protect mm_rb tree with a rwlock

On Tue, 13 Mar 2018, Laurent Dufour wrote: > This change is inspired by the Peter's proposal patch [1] which was > protecting the VMA using SRCU. Unfortunately, SRCU is not scaling well in > that particular case, and it is introducing major performance degradation > due to excessive scheduling

Re: [PATCH v9 16/24] mm: Introduce __page_add_new_anon_rmap()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > When dealing with speculative page fault handler, we may race with VMA > being split or merged. In this case the vma->vm_start and vm->vm_end > fields may not match the address the page fault is occurring. > > This can only happens when the VMA is

Re: [PATCH v9 15/24] mm: Introduce __vm_normal_page()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/include/linux/mm.h b/include/linux/mm.h > index a84ddc218bbd..73b8b99f482b 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -1263,8 +1263,11 @@ struct zap_details { > pgoff_t last_index; /*

Re: [PATCH v9 14/24] mm: Introduce __maybe_mkwrite()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/include/linux/mm.h b/include/linux/mm.h > index dfa81a638b7c..a84ddc218bbd 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -684,13 +684,18 @@ void free_compound_page(struct page *page); > * pte_mkwrite. But

Re: [PATCH v9 13/24] mm: Introduce __lru_cache_add_active_or_unevictable

On Tue, 13 Mar 2018, Laurent Dufour wrote: > The speculative page fault handler which is run without holding the > mmap_sem is calling lru_cache_add_active_or_unevictable() but the vm_flags > is not guaranteed to remain constant. > Introducing __lru_cache_add_active_or_unevictable() which has the

Re: [PATCH v9 12/24] mm/migrate: Pass vm_fault pointer to migrate_misplaced_page()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > migrate_misplaced_page() is only called during the page fault handling so > it's better to pass the pointer to the struct vm_fault instead of the vma. > > This way during the speculative page fault path the saved vma->vm_flags > could be used. > >

Re: [PATCH v9 11/24] mm: Cache some VMA fields in the vm_fault structure

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/include/linux/mm.h b/include/linux/mm.h > index ef6ef0627090..dfa81a638b7c 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -359,6 +359,12 @@ struct vm_fault { >* page table to avoid

[PATCH] tty:hvcs: Move Assignment for hvcsd->port.count

Move the assignment out of hvcsd->port.count from within the if () block so this patch fixes it. It is bad practice to have assignments within an if () block. Signed-off-by: Bryant G. Ly --- drivers/tty/hvc/hvcs.c | 3 ++- 1 file changed, 2 insertions(+), 1

Re: [PATCH 0/3] stop secondaries for reboot/shutdown

On 2018-04-01 16:06, Nicholas Piggin wrote: I'm rebasing and resending this series because the hard lockup messages are being seen in the field. Since last time, one of the patches was merged, and patches were split and reordered a bit. No major changes. This still hasn't been tested with the

Re: RFC on writel and writel_relaxed

On 3/29/2018 9:40 PM, Benjamin Herrenschmidt wrote: > On Thu, 2018-03-29 at 09:56 -0400, Sinan Kaya wrote: >> On 3/28/2018 11:55 AM, David Miller wrote: >>> From: Benjamin Herrenschmidt >>> Date: Thu, 29 Mar 2018 02:13:16 +1100 >>> Let's fix all archs, it's way

Re: [PATCH V2] powerpc: Fix oops due to wrong access of lppaca on non virtualized platform

On Mon, 2 Apr 2018 13:03:37 +0530 "Aneesh Kumar K.V" wrote: > Commit 8e0b634b1327 ("powerpc/64s: Do not allocate lppaca if we are not > virtualized") removed allocation of lppaca on non virtualized platform. But > with > CONFIG_PPC_SPLPAR enabled, we do access

[PATCH V2] powerpc: Fix oops due to wrong access of lppaca on non virtualized platform

Commit 8e0b634b1327 ("powerpc/64s: Do not allocate lppaca if we are not virtualized") removed allocation of lppaca on non virtualized platform. But with CONFIG_PPC_SPLPAR enabled, we do access lppaca non-virtualized platform in some code paths. Fix this but adding runtime check for virtualized

[PATCH] powerpc: Fix oops due to deferral of lpacca on non virtualized platform

Commit 8e0b634b1327 ("powerpc/64s: Do not allocate lppaca if we are not virtualized") removed allocation of lppaca on non virtualized platform. But with CONFIG_PPC_SPLPAR enabled, we do access lppaca non-virtualized platform in some code paths. Fix this but adding runtime check for virtualized

Re: [PATCH] Extract initrd free logic from arch-specific code.

* Shea Levy wrote: > > Please also put it into Documentation/features/. > > I switched this patch series (the latest revision v6 was just posted) to > using weak symbols instead of Kconfig. Does it still warrant documentation? Probably not. Thanks, Ingo

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

From: Mahesh Salgaonkar otherwise the fadump registration in new kexec-ed kernel complains that fadump is already registered. This makes new kernel to continue using fadump registered by previous kernel which may lead to invalid vmcore generation. Hence this patch

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

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

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

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

[PATCH v3 4/7] powerpc/fadump: exclude memory holes while reserving memory in second kernel.

From: Mahesh Salgaonkar The second kernel, during early boot after the crash, reserves rest of the memory above boot memory size to make sure it does not touch any of the dump memory area. It uses memblock_reserve() that reserves the specified memory region

[PATCH v3 3/7] powerpc/fadump: Reservationless firmware assisted dump

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

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

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

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

From: Mahesh Salgaonkar Currently the metadata region that holds crash info structure and ELF core header is placed towards the end of reserved memory area. This patch places it at the beginning of the reserved memory area. Signed-off-by: Mahesh Salgaonkar

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

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