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
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:
https://github.com/0day-ci/linux/
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 holes in reserved
> memory ranges where kernel has aske
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 soft
> > disable.
> >
> > This function is u
> 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 the random mmap address
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
> CPUs down as quickly
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 ope
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 spli
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; /* Highest
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 get_user_pag
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
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.
>
> Sig
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
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 deletion(-)
diff --git a/drivers/tty/
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 F
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 easier than fixing all drivers.
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 lppaca non-virtualized platform in
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 pla
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 pla
19 matches
Mail list logo
