Re: [PATCH] powerpc/le: enable RTAS events support

-off-by: Greg Kurz gk...@linux.vnet.ibm.com Reviewed-by: Laurent Dufour lduf...@linux.vnet.ibm.com --- arch/powerpc/include/asm/rtas.h | 46 ++ arch/powerpc/kernel/rtas.c | 11 arch/powerpc/kernel/rtasd.c |8 -- arch

[PATCH] powerpc/kvm/cma: Fix panic introduces by signed shift operation

iamjoonsoo@lge.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com --- arch/powerpc/kvm/book3s_64_mmu_hv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm

[PATCH] pseries/le: Fix endiannes issue in RTAS call from xmon

-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com --- arch/powerpc/xmon/xmon.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c index b988b5addf86..c8efbb37d6e0 100644 --- a/arch/powerpc/xmon/xmon.c +++ b/arch/powerpc

Re: pseries/le: Fix endiannes issue in RTAS call from xmon

On 26/11/2014 04:31, Michael Ellerman wrote: OK. You say LPAR, by which you mean under phyp I think. I haven't seen this under KVM, and it looks like KVM doesn't implement set-indicator so that would explain that. Yes LPAR implies phyp, and KVM don't implement set-indicator so this doesn't

[PATCH] pseries/le: Fix another endiannes issue in RTAS call from xmon

of the time unexisting RTAS function, which is silently ignored by RTAS. This fix addresses this hole. Reported-by: Michael Ellerman m...@ellerman.id.au Cc: sta...@vger.kernel.org Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com --- arch/powerpc/xmon/xmon.c | 1 + 1 file changed, 1

Re: [PATCH] pseries/le: Fix another endiannes issue in RTAS call from xmon

On 16/01/2015 04:02, Michael Ellerman wrote: On Thu, 2015-01-15 at 15:41 -0800, Tyrel Datwyler wrote: On 01/15/2015 02:19 PM, Michael Ellerman wrote: If this was on a powerkvm guest set-indicator should be present for hotplug (DLPAR) support. However, the surveillance indicator would not be

Re: [PATCH] pseries/le: Fix endiannes issue in RTAS call from xmon

On 15/01/2015 05:25, Michael Ellerman wrote: On Mon, 2014-11-24 at 15:07 +0100, Laurent Dufour wrote: On pseries system (LPAR) xmon failed to enter when running in LE mode, system is hunging. Inititating xmon will lead to such an output on the console: SysRq : Entering xmon cpu 0x15: Vector

[PATCH 0/2] Tracking user space vDSO remaping

hold. The next patch is adding the vDSO remap and unmap tracking to the powerpc architecture. Laurent Dufour (2): mm: Introducing arch_remap hook powerpc/mm: Tracking vDSO remap arch/powerpc/include/asm/mmu_context.h | 35 +++- arch/s390/include/asm/mmu_context.h

[PATCH 2/2] powerpc/mm: Tracking vDSO remap

remapping and unmapping. Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com --- arch/powerpc/include/asm/mmu_context.h | 35 +- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm

[PATCH 1/2] mm: Introducing arch_remap hook

the build, this patch adds the empty hook definition to the architectures that were not using the generic hook's definition. Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com --- arch/s390/include/asm/mmu_context.h | 6 ++ arch/um/include/asm/mmu_context.h| 5 + arch

Re: [PATCH v2 2/2] powerpc/mm: Tracking vDSO remap

On 25/03/2015 13:11, Ingo Molnar wrote: * Laurent Dufour lduf...@linux.vnet.ibm.com wrote: Some processes (CRIU) are moving the vDSO area using the mremap system call. As a consequence the kernel reference to the vDSO base address is no more valid and the signal return frame built once

[PATCH v3 0/2] Tracking user space vDSO remaping

to arch_remap through the __HAVE_ARCH_REMAP macro. This reduces considerably the first patch. Laurent Dufour (2): mm: Introducing arch_remap hook powerpc/mm: Tracking vDSO remap arch/powerpc/include/asm/mmu_context.h | 36 +- mm/mremap.c

[PATCH v3 1/2] mm: Introducing arch_remap hook

, unsigned long new_end); Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com --- mm/mremap.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/mm/mremap.c b/mm/mremap.c index 57dadc025c64..bafc234db45c 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -25,6 +25,7

[PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

remapping and unmapping. Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com --- arch/powerpc/include/asm/mmu_context.h | 36 +- 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm

Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

On 26/03/2015 10:48, Ingo Molnar wrote: * Benjamin Herrenschmidt b...@kernel.crashing.org wrote: +#define __HAVE_ARCH_REMAP +static inline void arch_remap(struct mm_struct *mm, +unsigned long old_start, unsigned long old_end, +unsigned long

Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

On 26/03/2015 10:43, Ingo Molnar wrote: * Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote: * Ingo Molnar mi...@kernel.org wrote: +#define __HAVE_ARCH_REMAP +static inline void arch_remap(struct mm_struct *mm, +

[PATCH v4 2/2] powerpc/mm: Tracking vDSO remap

remapping and unmapping. Moving or unmapping partially the vDSO lead to invalidate it from the kernel point of view. Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com --- arch/powerpc/include/asm/mmu_context.h | 32 +++- arch/powerpc/kernel/vdso.c | 39

[PATCH v4 1/2] mm: Introducing arch_remap hook

, unsigned long new_end); Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com --- mm/mremap.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/mm/mremap.c b/mm/mremap.c index 57dadc025c64..bafc234db45c 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -25,6 +25,7

[PATCH v4 0/2] Tracking user space vDSO remaping

patch. Thanks again, Ingo. Changes in v2: -- - Following the Ingo Molnar's advice, enabling the call to arch_remap through the __HAVE_ARCH_REMAP macro. This reduces considerably the first patch. Laurent Dufour (2): mm: Introducing arch_remap hook powerpc/mm: Tracking vDSO

Re: [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap

On 26/03/2015 19:55, Ingo Molnar wrote: * Laurent Dufour lduf...@linux.vnet.ibm.com wrote: +{ +unsigned long vdso_end, vdso_start; + +if (!mm-context.vdso_base) +return; +vdso_start = mm-context.vdso_base; + +#ifdef CONFIG_PPC64 +/* Calling is_32bit_task

[PATCH v2 2/2] powerpc/mm: Tracking vDSO remap

remapping and unmapping. Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com --- arch/powerpc/include/asm/mmu_context.h | 36 +- 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm

[PATCH v2 1/2] mm: Introducing arch_remap hook

, unsigned long new_end); Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com --- mm/mremap.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/mm/mremap.c b/mm/mremap.c index 57dadc025c64..bafc234db45c 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -25,6 +25,7

[PATCH v2 0/2] Tracking user space vDSO remaping

hold. The next patch is adding the vDSO remap and unmap tracking to the powerpc architecture. Changes in v2: -- - Following the Ingo Molnar's advice, enabling the call to arch_remap through the __HAVE_ARCH_REMAP macro. This reduces considerably the first patch. Laurent Dufour (2

Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

On 26/03/2015 15:17, Ingo Molnar wrote: * Laurent Dufour lduf...@linux.vnet.ibm.com wrote: I argue we should use the right condition to clear vdso_base: if the vDSO gets at least partially unmapped. Otherwise there's little point in the whole patch: either correctly track whether

Re: [PATCH 1/2] mm: Introducing arch_remap hook

On 23/03/2015 09:52, Ingo Molnar wrote: * Laurent Dufour lduf...@linux.vnet.ibm.com wrote: Some architecture would like to be triggered when a memory area is moved through the mremap system call. This patch is introducing a new arch_remap mm hook which is placed in the path of mremap

Re: [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook

On 13/04/2015 22:59, Andrew Morton wrote: On Mon, 13 Apr 2015 17:02:19 +0300 Kirill A. Shutemov kir...@shutemov.name wrote: Kirill, if I'm right with it, can you suggest the header where to put the generic mremap hook's (empty) body? I initially thought it would be enough to put it into

Re: powerpc: Enabling sys_kcmp for CRIU

On 11/05/2015 12:31, Michael Ellerman wrote: On Tue, 2015-05-05 at 15:30:21 UTC, Laurent Dufour wrote: The commit 8170a83f15ee (powerpc: Wireup the kcmp syscall to sys_ni) has disabled the kcmp syscall for powerpc. This has been done due to the use of unsigned long parameters which may

[PATCH] powerpc: Enabling sys_kcmp for CRIU

in or out of this system call, then a wrapper could be required, it will then be to care of it. As today this is not the case, it is safe to enable kcmp() on powerpc. Cc: Tony Breeds t...@bakeyournoodle.com Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com --- arch/powerpc/include/asm/systbl.h

Re: [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook

On 14/04/2015 21:38, Andrew Morton wrote: On Tue, 14 Apr 2015 11:26:13 +0200 Laurent Dufour lduf...@linux.vnet.ibm.com wrote: Do away with __HAVE_ARCH_REMAP and do it like this: arch/x/include/asm/y.h: extern void arch_remap(...); #define arch_remap arch_remap include/linux

[PATCH v5 1/3] mm: New mm hook framework

which doesn't need have nothing to do. The default hooks are defined in the generic header and are used in the case the architecture is not defining it. In a next step, mm hooks defined in include/asm-generic/mm_hooks.h should be moved here. Signed-off-by: Laurent Dufour lduf

[PATCH v5 2/3] mm: New arch_remap hook

-by: Laurent Dufour lduf...@linux.vnet.ibm.com --- include/linux/mm-arch-hooks.h | 9 + mm/mremap.c | 17 +++-- 2 files changed, 20 insertions(+), 6 deletions(-) diff --git a/include/linux/mm-arch-hooks.h b/include/linux/mm-arch-hooks.h index 63005e367abd

[PATCH v5 3/3] powerpc/mm: Tracking vDSO remap

remapping and unmapping. Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com Reviewed-by: Ingo Molnar mi...@kernel.org --- arch/powerpc/include/asm/mm-arch-hooks.h | 13 + arch/powerpc/include/asm/mmu_context.h | 23 ++- 2 files changed, 35 insertions(+), 1 deletion

[PATCH v5 0/3] Tracking user space vDSO remaping

the __HAVE_ARCH_REMAP macro. This reduces considerably the first patch. Laurent Dufour (3): mm: New mm hook framework mm: New arch_remap hook powerpc/mm: Tracking vDSO remap arch/alpha/include/asm/mm-arch-hooks.h | 15 +++ arch/arc/include/asm/mm-arch-hooks.h| 15

[RESEND PATCH v3 0/2] Tracking user space vDSO remaping

advice, enabling the call to arch_remap through the __HAVE_ARCH_REMAP macro. This reduces considerably the first patch. Laurent Dufour (2): mm: Introducing arch_remap hook powerpc/mm: Tracking vDSO remap arch/powerpc/include/asm/mmu_context.h | 36 +- mm

[RESEND PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

remapping and unmapping. Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com Reviewed-by: Ingo Molnar mi...@kernel.org --- arch/powerpc/include/asm/mmu_context.h | 36 +- 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm

[RESEND PATCH v3 1/2] mm: Introducing arch_remap hook

, unsigned long new_end); Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com Reviewed-by: Ingo Molnar mi...@kernel.org --- mm/mremap.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/mm/mremap.c b/mm/mremap.c index 2dc44b1cb1df..009db5565893 100644 --- a/mm

Re: [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook

On 13/04/2015 16:02, Kirill A. Shutemov wrote: On Mon, Apr 13, 2015 at 04:35:21PM +0300, Pavel Emelyanov wrote: On 04/13/2015 04:21 PM, Laurent Dufour wrote: On 13/04/2015 15:13, Kirill A. Shutemov wrote: On Mon, Apr 13, 2015 at 02:41:22PM +0200, Laurent Dufour wrote: On 13/04/2015 13:58

Re: [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook

On 13/04/2015 13:58, Kirill A. Shutemov wrote: On Mon, Apr 13, 2015 at 11:56:27AM +0200, Laurent Dufour wrote: Some architecture would like to be triggered when a memory area is moved through the mremap system call. This patch is introducing a new arch_remap mm hook which is placed

Re: [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook

On 13/04/2015 15:13, Kirill A. Shutemov wrote: On Mon, Apr 13, 2015 at 02:41:22PM +0200, Laurent Dufour wrote: On 13/04/2015 13:58, Kirill A. Shutemov wrote: On Mon, Apr 13, 2015 at 11:56:27AM +0200, Laurent Dufour wrote: Some architecture would like to be triggered when a memory area is moved

Re: [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook

On 13/04/2015 16:32, Pavel Emelyanov wrote: I initially thought it would be enough to put it into asm-generic/mmu_context.h, expecting it works as asm-generic/pgtable.h. But that's not the case. It probably worth at some point rework all asm/mmu_context.h to include asm-generic/mmu_context.h

Re: mm: new mm hook framework

Parent: e81f2d22370f8231cb7f13f454bcc8c0eb4e23f2 Refname:refs/heads/master Author: Laurent Dufour lduf...@linux.vnet.ibm.com AuthorDate: Wed Jun 24 16:56:16 2015 -0700 Committer: Linus Torvalds torva...@linux-foundation.org CommitDate: Wed Jun 24 17:49:41 2015 -0700 mm: new mm

[PATCH v2] mm: cleaning per architecture MM hook header files

architecture. Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com Suggested-by: Geert Uytterhoeven ge...@linux-m68k.org CC: Andrew Morton a...@linux-foundation.org CC: Vineet Gupta vineet.gup...@synopsys.com CC: linux-a...@vger.kernel.org CC: linux...@kvack.org CC: linux-kernel@vger.kernel.org

Re: [PATCH] mm: cleaning per architecture MM hook header files

@@ -/* - * Architecture specific mm hooks - * - * Copyright (C) 2015, IBM Corporation - * Author: Laurent Dufour lduf...@linux.vnet.ibm.com - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published

[PATCH] mm: cleaning per architecture MM hook header files

architecture asm/include/Kbuild file. The powerpc architecture is not impacted here since this architecture has to defined the arch_remap MM hook. Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com Suggested-by: Geert Uytterhoeven ge...@linux-m68k.org CC: Andrew Morton a...@linux

Re: [PATCH] powerpc/hvsi: Fix endianness issues in the HVSI driver

On 03/08/2015 13:00, David Laight wrote: From: Laurent Dufour Sent: 31 July 2015 10:30 This patch fixes several endianness issues detected when running the HVSI driver in little endian mode. These issues are raised in little endian mode because the data exchanged in memory between

Re: [PATCH] powerpc/hvsi: Fix endianness issues in the HVSI driver

On 04/08/2015 02:51, Michael Ellerman wrote: On Fri, 2015-07-31 at 11:29 +0200, Laurent Dufour wrote: This patch fixes several endianness issues detected when running the HVSI driver in little endian mode. These issues are raised in little endian mode because the data exchanged in memory

[PATCH] powerpc/hvsi: Fix endianness issues in the HVSI driver

This patch fixes several endianness issues detected when running the HVSI driver in little endian mode. These issues are raised in little endian mode because the data exchanged in memory between the kernel and the hypervisor has to be in big endian format. Signed-off-by: Laurent Dufour lduf

Re: linux-next: build failure after merge of the akpm-current tree

On 21/10/2015 12:08, Michael Ellerman wrote: > On Wed, 2015-10-21 at 16:59 +1100, Stephen Rothwell wrote: >> Hi Andrew, >> >> After merging the akpm-current tree, today's linux-next build (powerpc >> allnoconfig) failed like this: > >> arch/powerpc/include/asm/pgtable.h: In function 'pte_pgprot':

[PATCH 0/3] mm/powerpc: enabling memory soft dirty tracking

e clearing the soft dirty bit. The PTE were not cleared before being modified, leading to hang on ppc64. The second patch is fixing a build issue when the transparent huge page is not enabled. The third patch is introducing the soft dirty tracking in the powerpc architecture code. Laurent Dufour

[PATCH 3/3] powerpc/mm: Add page soft dirty tracking

when the page is swapped out. The _PAGE_SWP_SOFT_DIRTY bit is dynamically put after the swap type in the swap pte. A check is added to ensure that the bit is not overwritten by _PAGE_HPTEFLAGS. Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> CC: Aneesh Kumar K.V <

[PATCH 2/3] mm: clear_soft_dirty_pmd requires THP

Don't build clear_soft_dirty_pmd() if the transparent huge pages are not enabled. Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> CC: Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com> --- fs/proc/task_mmu.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deleti

[PATCH 1/3] mm: clearing pte in clear_soft_dirty()

Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> CC: Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com> --- fs/proc/task_mmu.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index e2d46adb54b4..c9454ee39b28 100644 --

Re: [PATCH v2] mm: cleaning per architecture MM hook header files

On 10/07/2015 01:09, Andrew Morton wrote: On Wed, 1 Jul 2015 12:17:33 +0200 Laurent Dufour lduf...@linux.vnet.ibm.com wrote: The commit 2ae416b142b6 (mm: new mm hook framework) introduced an empty header file (mm-arch-hooks.h) for every architecture, even those which doesn't need

Re: kernel BUG at drivers/scsi/scsi_lib.c:1096!

On 20/11/2015 13:10, Michael Ellerman wrote: > On Thu, 2015-11-19 at 00:23 -0800, Christoph Hellwig wrote: > >> It's pretty much guaranteed a block layer bug, most likely in the >> merge bios to request infrastucture where we don't obey the merging >> limits properly. >> >> Does either of you

Re: kernel BUG at drivers/scsi/scsi_lib.c:1096!

On 23/11/2015 00:20, Mark Salter wrote: > On Sun, 2015-11-22 at 00:56 +0800, Ming Lei wrote: >> On Sat, 21 Nov 2015 12:30:14 +0100 >> Laurent Dufour <lduf...@linux.vnet.ibm.com> wrote: >> >>> On 20/11/2015 13:10, Michael Ellerman wrote: >>>> On T

Re: kernel BUG at drivers/scsi/scsi_lib.c:1096!

On 23/11/2015 16:13, Pratyush Anand wrote: > On 23/11/2015:02:57:19 PM, Laurent Dufour wrote: >> On 23/11/2015 00:20, Mark Salter wrote: >>> On Sun, 2015-11-22 at 00:56 +0800, Ming Lei wrote: >>>> On Sat, 21 Nov 2015 12:30:14 +0100 >>>> Laurent

Re: kernel BUG at drivers/scsi/scsi_lib.c:1096!

On 23/11/2015 16:27, Ming Lei wrote: > On Mon, Nov 23, 2015 at 11:20 PM, Laurent Dufour > <lduf...@linux.vnet.ibm.com> wrote: >>> >>> Reverting above commit on top if 4.4-rc1 seems to fix the problem for me. >> >> That's what I mentioned earlier

Re: kernel BUG at drivers/scsi/scsi_lib.c:1096!

On 20/11/2015 13:10, Michael Ellerman wrote: > On Thu, 2015-11-19 at 00:23 -0800, Christoph Hellwig wrote: > >> It's pretty much guaranteed a block layer bug, most likely in the >> merge bios to request infrastucture where we don't obey the merging >> limits properly. >> >> Does either of you

[PATCH] autofs4: Fix endless loop in autofs4_write

hemaw.net> Cc: aut...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: sta...@vger.kernel.org Reviewed-by: Greg Kurz <gr...@kaod.org> Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> Fixes: e9a7c2f1a548 ("autofs4: coding style fixes") --- fs/autofs4/waitq.c | 7

Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes

On 21/04/2016 18:00, Laurent Dufour wrote: > On 13/04/2016 07:14, Michael Ellerman wrote: >> On Mon, 2016-04-11 at 09:40 +0200, Laurent Dufour wrote: >>> On 07/04/2016 23:49, Michael Ellerman wrote: >>>> On 7 April 2016 7:23:46 pm AEST, Laurent Dufour >>&

Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes

On 07/04/2016 23:49, Michael Ellerman wrote: > > > On 7 April 2016 7:23:46 pm AEST, Laurent Dufour <lduf...@linux.vnet.ibm.com> > wrote: >> On 16/02/2016 09:59, Anshuman Khandual wrote: >>> This patch series adds twelve new ELF core note sections which can

Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes

On 16/02/2016 09:59, Anshuman Khandual wrote: > This patch series adds twelve new ELF core note sections which can > be used with existing ptrace request PTRACE_GETREGSET-SETREGSET for accessing > various transactional memory and other miscellaneous debug register sets on > powerpc platform.

Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes

On 13/04/2016 07:14, Michael Ellerman wrote: > On Mon, 2016-04-11 at 09:40 +0200, Laurent Dufour wrote: >> On 07/04/2016 23:49, Michael Ellerman wrote: >>> On 7 April 2016 7:23:46 pm AEST, Laurent Dufour >>> <lduf...@linux.vnet.ibm.com> wrote: >>>&g

About the patch " block: flush writeback dwork before detaching a bdev inode from it"

Hi Jan, This is about the patch "block: flush writeback dwork before detaching a bdev inode from it" you sent a month ago to fix a panic hit by Dimitry: https://patchwork.kernel.org/patch/9187409/ We hit the same issue on our side, and gave your patch a try, and it fixed the issue. Is there any

Re: About the patch " block: flush writeback dwork before detaching a bdev inode from it"

On 25/07/2016 15:29, Jan Kara wrote: > Hi! > > On Mon 25-07-16 09:48:37, Laurent Dufour wrote: >> This is about the patch "block: flush writeback dwork before detaching a >> bdev inode from it" you sent a month ago to fix a panic hit by Dimitry: >> https

Re: [v4] powerpc: Export thread_struct.used_vr/used_vsr to user space

On 07/07/2016 15:21, Benjamin Herrenschmidt wrote: > On Thu, 2016-07-07 at 15:12 +0200, Laurent Dufour wrote: >> >> Basically, CRIU checkpoints the process register's state through the >> ptrace API, and it restores it through a signal frame at restart time. >> This is

Re: [v4] powerpc: Export thread_struct.used_vr/used_vsr to user space

On 07/07/2016 13:15, Michael Ellerman wrote: > On Thu, 2016-07-07 at 07:49:36 UTC, Simon Guo wrote: >> From: Simon Guo >> >> These 2 fields track whether user process has used Altivec/VSX >> registers or not. They are used by kernel to setup signal frame >> on user stack

Re: [PATCH] mm/cgroup: avoid panic when init with low memory

On 20/02/2017 18:42, Michal Hocko wrote: > On Mon 20-02-17 18:09:43, Laurent Dufour wrote: >> On 20/02/2017 14:01, Michal Hocko wrote: >>> On Wed 15-02-17 11:36:09, Laurent Dufour wrote: >>>> The system may panic when initialisation is done when almost all the >&

Re: [PATCH] mm/cgroup: avoid panic when init with low memory

On 20/02/2017 14:01, Michal Hocko wrote: > On Wed 15-02-17 11:36:09, Laurent Dufour wrote: >> The system may panic when initialisation is done when almost all the >> memory is assigned to the huge pages using the kernel command line >> parameter hugepage=. Panic may occur

[PATCH v2 2/2] mm/cgroup: delay soft limit data allocation

Until a soft limit is set to a cgroup, the soft limit data are useless so delay this allocation when a limit is set. Suggested-by: Michal Hocko <mho...@kernel.org> Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> --- mm/memco

[PATCH v2 0/2] mm/cgroup soft limit data allocation

cks to the first patch - differ also the allocation of the pointer table - return error in the case allocation failed Laurent Dufour (2): mm/cgroup: avoid panic when init with low memory mm/cgroup: delay soft limit data allocation mm/memcontrol.c |

[PATCH v2 1/2] mm/cgroup: avoid panic when init with low memory

which assumes that these data are allocated. As mem_cgroup_soft_limit_reclaim() is best effort, it should return when these data are not yet allocated. This patch also fixes potential null pointer access in mem_cgroup_remove_from_trees() and mem_cgroup_update_tree(). Signed-off-by: Laurent

Re: [PATCH 2/2] mm/cgroup: delay soft limit data allocation

On 22/02/2017 18:11, Michal Hocko wrote: > On Wed 22-02-17 16:58:11, Laurent Dufour wrote: > [...] >> static struct mem_cgroup_tree_per_node * >> soft_limit_tree_node(int nid) >> { >> @@ -465,6 +497,8 @@ static void mem_cgroup_update_tree(struct mem_cgroup

Re: [PATCH 2/2] mm/cgroup: delay soft limit data allocation

On 23/02/2017 02:16, Balbir Singh wrote: > On Wed, Feb 22, 2017 at 04:58:11PM +0100, Laurent Dufour wrote: >> Until a soft limit is set to a cgroup, the soft limit data are useless >> so delay this allocation when a limit is set. >> >> Suggested-by: Michal Hocko <mh

[PATCH 1/2] mm/cgroup: avoid panic when init with low memory

which assumes that these data are allocated. As mem_cgroup_soft_limit_reclaim() is best effort, it should return when these data are not yet allocated. Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> --- mm/memcontrol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) dif

[PATCH 0/2] mm/cgroup soft limit data allocation

The first patch of this series is fixing a panic occurring when soft limit data allocation is using soft limit data. The second patch, as suggested by Michal Hocko, is pushing forward by delaying the soft limit data allocation when a soft limit is set. Laurent Dufour (2): mm/cgroup: avoid

[PATCH 2/2] mm/cgroup: delay soft limit data allocation

Until a soft limit is set to a cgroup, the soft limit data are useless so delay this allocation when a limit is set. Suggested-by: Michal Hocko <mho...@kernel.org> Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> --- mm/memco

Re: [PATCH 2/2] mm/cgroup: delay soft limit data allocation

On 22/02/2017 19:24, Michal Hocko wrote: > On Wed 22-02-17 18:50:19, Laurent Dufour wrote: >> On 22/02/2017 18:11, Michal Hocko wrote: >>> On Wed 22-02-17 16:58:11, Laurent Dufour wrote: >>> [...] >>>> static struct mem_cgroup_tree_per_no

[PATCH 2/3] powerpc/mm: handle VM_FAULT_RETRY earlier

In do_page_fault() if handle_mm_fault() returns VM_FAULT_RETRY, retry the page fault handling before anything else. This would simplify the handling of the mmap_sem lock in this part of the code. Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> --- arch/powerpc/mm/fault.

[PATCH 0/3] powerpc/mm: page fault handler cleaning

Torvalds 26178ec11ef3 ("x86: mm: consolidate VM_FAULT_RETRY handling") 7fb08eca4527 ("x86: mm: move mmap_sem unlock from mm_fault_error() to caller") Laurent Dufour (3): powerpc/mm: move mmap_sem unlock up from do_sigbus powerpc/mm: handle VM_FAULT_RETRY earlier power

[PATCH 3/3] powerpc/mm: move mmap_sem unlocking in do_page_fault()

Since the fault retry is now handled earlier, we can release the mmap_sem lock earlier too and remove later unlocking previously done in mm_fault_error(). Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> --- arch/powerpc/mm/fault.c | 19 --- 1 file changed, 4 inse

[PATCH 1/3] powerpc/mm: move mmap_sem unlock up from do_sigbus

Move mmap_sem releasing in the do_sigbus()'s unique caller : mm_fault_error() No functional changes. Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> --- arch/powerpc/mm/fault.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/mm/fault.c

[PATCH] mm/cgroup: avoid panic when init with low memory

which assumes that these data are allocated. As mem_cgroup_soft_limit_reclaim() is best effort, it should return when these data are not yet allocated. Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> --- mm/memcontrol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) dif

Re: [PATCH 0/3] powerpc/mm: page fault handler cleaning

Kindly ping... On 14/02/2017 17:45, Laurent Dufour wrote: > This series attempts to clean the page fault handler in the way it has > been done previously for the x86 architecture [1]. > > The goal is to manage the mmap_sem earlier and only in > do_page_fault(). This done by han

[PATCH] powerpc/pseries: Fix stack corruption in htpe code

buffer in pSeries_lpar_flush_hash_range() to rely on the global define PLPAR_HCALL9_BUFSIZE (no functional change here). Fixes: 1a5272866f87 ("powerpc: Optimize hugepage invalidate") Cc: <sta...@vger.kernel.org> Cc: Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com> Signed-

Re: [RFC v2 6/7] mm/powerpc: Use generic VDSO remap and unmap functions

SO and then catching a signal on 4.9-rc4 and using CRIU on top of 4.8 with sightly changes to due minor upstream changes. Reviewed-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> Tested-by: Laurent Dufour <lduf...@linux.vnet.ibm.com>

Re: [PATCH] powerpc/pseries: Fix stack corruption in htpe code

On 07/10/2016 01:08, Benjamin Herrenschmidt wrote: > On Thu, 2016-10-06 at 20:32 +0530, Aneesh Kumar K.V wrote: >> Laurent Dufour <lduf...@linux.vnet.ibm.com> writes: >> > > (Off-list) > > Did that bug make it to RHEL/CentOS/SLES ? Yes all of them are pot

Re: [PATCH 1/5] locking: Introduce range reader/writer lock

On 07/03/2017 06:03, Davidlohr Bueso wrote: > This implements a sleepable range rwlock, based on interval tree, serializing > conflicting/intersecting/overlapping ranges within the tree. The largest range > is given by [0, ~0 - 1] (inclusive). Unlike traditional locks, range locking > involves

Re: [PATCH 1/5] locking: Introduce range reader/writer lock

On 07/03/2017 06:03, Davidlohr Bueso wrote: > This implements a sleepable range rwlock, based on interval tree, serializing > conflicting/intersecting/overlapping ranges within the tree. The largest range > is given by [0, ~0 - 1] (inclusive). Unlike traditional locks, range locking > involves

Re: [PATCH 1/5] locking: Introduce range reader/writer lock

On 28/03/2017 18:58, Kirill A. Shutemov wrote: > On Tue, Mar 28, 2017 at 09:39:18AM -0700, Davidlohr Bueso wrote: >> I'll wait to see if there are any more concerns and send a v2 with your >> corrections. > > Have you tried drop-in replacement of mmap_sem with full range lock? > It would be

Re: [PATCH 2/3] powerpc/mm: handle VM_FAULT_RETRY earlier

On 21/03/2017 10:12, Aneesh Kumar K.V wrote: > Laurent Dufour <lduf...@linux.vnet.ibm.com> writes: > >> In do_page_fault() if handle_mm_fault() returns VM_FAULT_RETRY, retry >> the page fault handling before anything else. >> >> This would simplify the handli

Re: [PATCH 1/5] locking: Introduce range reader/writer lock

Le Tue, 28 Mar 2017 09:39:18 -0700, Davidlohr Bueso a écrit : > I'll wait to see if there are any more concerns and send a v2 with > your corrections. Hi Bavidlohr, I think there is a major issue regarding the task catching a signal in wait_for_range(). I can see it when a

Re: [PATCH 2/6] locking: Introduce range reader/writer lock

On 06/04/2017 10:46, Davidlohr Bueso wrote: > This implements a sleepable range rwlock, based on interval tree, serializing > conflicting/intersecting/overlapping ranges within the tree. The largest range > is given by [0, ~0 - 1] (inclusive). Unlike traditional locks, range locking > involves

Re: [RFC 2/4] Deactivate mmap_sem assert

On 19/04/2017 14:30, Peter Zijlstra wrote: > On Wed, Apr 19, 2017 at 02:18:25PM +0200, Laurent Dufour wrote: >> When mmap_sem will be moved to a range lock, some assertion done in >> the code are no more valid, like the one ensuring mmap_sem is held. >> > > Why are they

Re: [PATCH 2/6] locking: Introduce range reader/writer lock

On 20/04/2017 18:01, Davidlohr Bueso wrote: >>> +int range_read_trylock(struct range_rwlock_tree *tree, struct >>> range_rwlock *lock) >>> +{ >>> +int ret = true; >>> +unsigned long flags; >>> +struct interval_tree_node *node; >>> + >>> +spin_lock_irqsave(>lock, flags); >>> + >>> +

Re: [PATCH 2/6] locking: Introduce range reader/writer lock

On 13/04/2017 10:38, Jan Kara wrote: > On Thu 13-04-17 10:07:48, Laurent Dufour wrote: >> On 06/04/2017 18:50, Davidlohr Bueso wrote: >>> On Thu, 06 Apr 2017, Laurent Dufour wrote: >>> >>>> How is 'seqnum' wrapping handled here ? >>>> I'd

Re: [PATCH 2/6] locking: Introduce range reader/writer lock

On 06/04/2017 18:50, Davidlohr Bueso wrote: > On Thu, 06 Apr 2017, Laurent Dufour wrote: > >> How is 'seqnum' wrapping handled here ? >> I'd rather see something like time_before() here, isn't it ? > > Its a 64bit counter, no overflows. I should have miss something,

[RFC 1/2] mm: Uncharge poisoned pages

When page are poisoned, they should be uncharged from the root memory cgroup. Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> --- mm/memory-failure.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 27f7210e7fab..00bd39d3d4cb

[RFC 2/2] mm: skip HWPoisoned pages when onlining pages

The commit b023f46813cd ("memory-hotplug: skip HWPoisoned page when offlining pages") skip the HWPoisoned pages when offlining pages, but this should be skipped when onlining the pages too. Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> --- mm/memory_hotplug.c | 2 ++

Re: [RFC 4/4] Change mmap_sem to range lock

On 20/04/2017 16:37, Peter Zijlstra wrote: > On Thu, Apr 20, 2017 at 04:28:20PM +0200, Laurent Dufour wrote: >> [resent this patch which seems to have not reached the mailing lists] > > Probably because its too big at ~180k ? Probably, but this time it has reached linux-mm ... at least.

  1   2   3   4   5   6   7   8   9   10   >