From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>,
Pavel Emelyanov <xemul@parallels.com>,
Hugh Dickins <hughd@google.com>,
linux-kernel@vger.kernel.org, criu@openvz.org,
linux-mm@kvack.org, Paul Mackerras <paulus@samba.org>,
Mel Gorman <mgorman@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org, Ingo Molnar <mingo@kernel.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
cov@codeaurora.org
Subject: Re: [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook
Date: Mon, 13 Apr 2015 17:26:55 +0300 [thread overview]
Message-ID: <20150413142655.GA14646@node.dhcp.inet.fi> (raw)
In-Reply-To: <552BCE87.8040103@linux.vnet.ibm.com>
On Mon, Apr 13, 2015 at 04:11:19PM +0200, Laurent Dufour wrote:
> 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, 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 in the
> >>>>>>> path of mremap, and is called before the old area is unmapped (and the
> >>>>>>> arch_unmap hook is called).
> >>>>>>>
> >>>>>>> The architectures which need to call this hook should define
> >>>>>>> __HAVE_ARCH_REMAP in their asm/mmu_context.h and provide the arch_remap
> >>>>>>> service with the following prototype:
> >>>>>>> void arch_remap(struct mm_struct *mm,
> >>>>>>> unsigned long old_start, unsigned long old_end,
> >>>>>>> unsigned long new_start, unsigned long new_end);
> >>>>>>>
> >>>>>>> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
> >>>>>>> Reviewed-by: Ingo Molnar <mingo@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/mremap.c
> >>>>>>> +++ b/mm/mremap.c
> >>>>>>> @@ -25,6 +25,7 @@
> >>>>>>>
> >>>>>>> #include <asm/cacheflush.h>
> >>>>>>> #include <asm/tlbflush.h>
> >>>>>>> +#include <asm/mmu_context.h>
> >>>>>>>
> >>>>>>> #include "internal.h"
> >>>>>>>
> >>>>>>> @@ -286,13 +287,19 @@ static unsigned long move_vma(struct vm_area_struct *vma,
> >>>>>>> old_len = new_len;
> >>>>>>> old_addr = new_addr;
> >>>>>>> new_addr = -ENOMEM;
> >>>>>>> - } else if (vma->vm_file && vma->vm_file->f_op->mremap) {
> >>>>>>> - err = vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
> >>>>>>> - if (err < 0) {
> >>>>>>> - move_page_tables(new_vma, new_addr, vma, old_addr,
> >>>>>>> - moved_len, true);
> >>>>>>> - return err;
> >>>>>>> + } else {
> >>>>>>> + if (vma->vm_file && vma->vm_file->f_op->mremap) {
> >>>>>>> + err = vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
> >>>>>>> + if (err < 0) {
> >>>>>>> + move_page_tables(new_vma, new_addr, vma,
> >>>>>>> + old_addr, moved_len, true);
> >>>>>>> + return err;
> >>>>>>> + }
> >>>>>>> }
> >>>>>>> +#ifdef __HAVE_ARCH_REMAP
> >>>>>>
> >>>>>> It would be cleaner to provide dummy arch_remap() for !__HAVE_ARCH_REMAP
> >>>>>> in some generic header.
> >>>>>
> >>>>> The idea was to not impact all the architectures as arch_unmap(),
> >>>>> arch_dup_mmap() or arch_exit_mmap() implies.
> >>>>>
> >>>>> I look at the headers where such a dummy arch_remap could be put but I
> >>>>> can't figure out one which will not impact all the architecture.
> >>>>> What about defining a dummy service earlier in mm/remap.c in the case
> >>>>> __HAVE_ARCH_REMAP is not defined ?
> >>>>> Something like :
> >>>>> #ifndef __HAVE_ARCH_REMAP
> >>>>> static inline void void arch_remap(struct mm_struct *mm,
> >>>>> unsigned long old_start,
> >>>>> unsigned long old_end,
> >>>>> unsigned long new_start,
> >>>>> unsigned long new_end)
> >>>>> {
> >>>>> }
> >>>>> #endif
> >>>>
> >>>> Or just #define arch_remap(...) do { } while (0)
> >>>>
> >>>
> >>> I guessed you wanted the arch_remap() prototype to be exposed somewhere
> >>> in the code.
> >>>
> >>> To be honest, I can't find the benefit of defining a dummy arch_remap()
> >>> in mm/remap.c if __HAVE_ARCH_REMAP is not defined instead of calling it
> >>> in move_vma if __HAVE_ARCH_REMAP is defined.
> >>> Is it really what you want ?
> >>
> >> I think Kirill meant something like e.g. the arch_enter_lazy_mmu_mode()
> >> is implemented and called in mm/mremap.c -- the "generic" part is in the
> >> include/asm-generic/pgtable.h and those architectures willing to have
> >> their own implementation are in arch/$arch/...
> >>
> >> 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
> > <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> at the end as we do for <asm/pgtable.h>.
> > But that's outside the scope of the patchset, I guess.
> >
> > I don't see any better candidate for such dummy header. :-/
>
> Clearly, I'm not confortable with a rewrite of <asm/mmu_context.h> :(
>
> So what about this patch, is this v3 acceptable ?
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
--
Kirill A. Shutemov
WARNING: multiple messages have this Message-ID (diff)
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Cc: Pavel Emelyanov <xemul@parallels.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Hugh Dickins <hughd@google.com>, Rik van Riel <riel@redhat.com>,
Mel Gorman <mgorman@suse.de>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Ingo Molnar <mingo@kernel.org>,
linuxppc-dev@lists.ozlabs.org, cov@codeaurora.org,
criu@openvz.org
Subject: Re: [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook
Date: Mon, 13 Apr 2015 17:26:55 +0300 [thread overview]
Message-ID: <20150413142655.GA14646@node.dhcp.inet.fi> (raw)
In-Reply-To: <552BCE87.8040103@linux.vnet.ibm.com>
On Mon, Apr 13, 2015 at 04:11:19PM +0200, Laurent Dufour wrote:
> 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, 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 in the
> >>>>>>> path of mremap, and is called before the old area is unmapped (and the
> >>>>>>> arch_unmap hook is called).
> >>>>>>>
> >>>>>>> The architectures which need to call this hook should define
> >>>>>>> __HAVE_ARCH_REMAP in their asm/mmu_context.h and provide the arch_remap
> >>>>>>> service with the following prototype:
> >>>>>>> void arch_remap(struct mm_struct *mm,
> >>>>>>> unsigned long old_start, unsigned long old_end,
> >>>>>>> unsigned long new_start, unsigned long new_end);
> >>>>>>>
> >>>>>>> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
> >>>>>>> Reviewed-by: Ingo Molnar <mingo@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/mremap.c
> >>>>>>> +++ b/mm/mremap.c
> >>>>>>> @@ -25,6 +25,7 @@
> >>>>>>>
> >>>>>>> #include <asm/cacheflush.h>
> >>>>>>> #include <asm/tlbflush.h>
> >>>>>>> +#include <asm/mmu_context.h>
> >>>>>>>
> >>>>>>> #include "internal.h"
> >>>>>>>
> >>>>>>> @@ -286,13 +287,19 @@ static unsigned long move_vma(struct vm_area_struct *vma,
> >>>>>>> old_len = new_len;
> >>>>>>> old_addr = new_addr;
> >>>>>>> new_addr = -ENOMEM;
> >>>>>>> - } else if (vma->vm_file && vma->vm_file->f_op->mremap) {
> >>>>>>> - err = vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
> >>>>>>> - if (err < 0) {
> >>>>>>> - move_page_tables(new_vma, new_addr, vma, old_addr,
> >>>>>>> - moved_len, true);
> >>>>>>> - return err;
> >>>>>>> + } else {
> >>>>>>> + if (vma->vm_file && vma->vm_file->f_op->mremap) {
> >>>>>>> + err = vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
> >>>>>>> + if (err < 0) {
> >>>>>>> + move_page_tables(new_vma, new_addr, vma,
> >>>>>>> + old_addr, moved_len, true);
> >>>>>>> + return err;
> >>>>>>> + }
> >>>>>>> }
> >>>>>>> +#ifdef __HAVE_ARCH_REMAP
> >>>>>>
> >>>>>> It would be cleaner to provide dummy arch_remap() for !__HAVE_ARCH_REMAP
> >>>>>> in some generic header.
> >>>>>
> >>>>> The idea was to not impact all the architectures as arch_unmap(),
> >>>>> arch_dup_mmap() or arch_exit_mmap() implies.
> >>>>>
> >>>>> I look at the headers where such a dummy arch_remap could be put but I
> >>>>> can't figure out one which will not impact all the architecture.
> >>>>> What about defining a dummy service earlier in mm/remap.c in the case
> >>>>> __HAVE_ARCH_REMAP is not defined ?
> >>>>> Something like :
> >>>>> #ifndef __HAVE_ARCH_REMAP
> >>>>> static inline void void arch_remap(struct mm_struct *mm,
> >>>>> unsigned long old_start,
> >>>>> unsigned long old_end,
> >>>>> unsigned long new_start,
> >>>>> unsigned long new_end)
> >>>>> {
> >>>>> }
> >>>>> #endif
> >>>>
> >>>> Or just #define arch_remap(...) do { } while (0)
> >>>>
> >>>
> >>> I guessed you wanted the arch_remap() prototype to be exposed somewhere
> >>> in the code.
> >>>
> >>> To be honest, I can't find the benefit of defining a dummy arch_remap()
> >>> in mm/remap.c if __HAVE_ARCH_REMAP is not defined instead of calling it
> >>> in move_vma if __HAVE_ARCH_REMAP is defined.
> >>> Is it really what you want ?
> >>
> >> I think Kirill meant something like e.g. the arch_enter_lazy_mmu_mode()
> >> is implemented and called in mm/mremap.c -- the "generic" part is in the
> >> include/asm-generic/pgtable.h and those architectures willing to have
> >> their own implementation are in arch/$arch/...
> >>
> >> 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
> > <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> at the end as we do for <asm/pgtable.h>.
> > But that's outside the scope of the patchset, I guess.
> >
> > I don't see any better candidate for such dummy header. :-/
>
> Clearly, I'm not confortable with a rewrite of <asm/mmu_context.h> :(
>
> So what about this patch, is this v3 acceptable ?
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
--
Kirill A. Shutemov
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Cc: Pavel Emelyanov <xemul@parallels.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Hugh Dickins <hughd@google.com>, Rik van Riel <riel@redhat.com>,
Mel Gorman <mgorman@suse.de>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Ingo Molnar <mingo@kernel.org>,
linuxppc-dev@lists.ozlabs.org, cov@codeaurora.org,
criu@openvz.org
Subject: Re: [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook
Date: Mon, 13 Apr 2015 17:26:55 +0300 [thread overview]
Message-ID: <20150413142655.GA14646@node.dhcp.inet.fi> (raw)
In-Reply-To: <552BCE87.8040103@linux.vnet.ibm.com>
On Mon, Apr 13, 2015 at 04:11:19PM +0200, Laurent Dufour wrote:
> 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, 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 in the
> >>>>>>> path of mremap, and is called before the old area is unmapped (and the
> >>>>>>> arch_unmap hook is called).
> >>>>>>>
> >>>>>>> The architectures which need to call this hook should define
> >>>>>>> __HAVE_ARCH_REMAP in their asm/mmu_context.h and provide the arch_remap
> >>>>>>> service with the following prototype:
> >>>>>>> void arch_remap(struct mm_struct *mm,
> >>>>>>> unsigned long old_start, unsigned long old_end,
> >>>>>>> unsigned long new_start, unsigned long new_end);
> >>>>>>>
> >>>>>>> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
> >>>>>>> Reviewed-by: Ingo Molnar <mingo@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/mremap.c
> >>>>>>> +++ b/mm/mremap.c
> >>>>>>> @@ -25,6 +25,7 @@
> >>>>>>>
> >>>>>>> #include <asm/cacheflush.h>
> >>>>>>> #include <asm/tlbflush.h>
> >>>>>>> +#include <asm/mmu_context.h>
> >>>>>>>
> >>>>>>> #include "internal.h"
> >>>>>>>
> >>>>>>> @@ -286,13 +287,19 @@ static unsigned long move_vma(struct vm_area_struct *vma,
> >>>>>>> old_len = new_len;
> >>>>>>> old_addr = new_addr;
> >>>>>>> new_addr = -ENOMEM;
> >>>>>>> - } else if (vma->vm_file && vma->vm_file->f_op->mremap) {
> >>>>>>> - err = vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
> >>>>>>> - if (err < 0) {
> >>>>>>> - move_page_tables(new_vma, new_addr, vma, old_addr,
> >>>>>>> - moved_len, true);
> >>>>>>> - return err;
> >>>>>>> + } else {
> >>>>>>> + if (vma->vm_file && vma->vm_file->f_op->mremap) {
> >>>>>>> + err = vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
> >>>>>>> + if (err < 0) {
> >>>>>>> + move_page_tables(new_vma, new_addr, vma,
> >>>>>>> + old_addr, moved_len, true);
> >>>>>>> + return err;
> >>>>>>> + }
> >>>>>>> }
> >>>>>>> +#ifdef __HAVE_ARCH_REMAP
> >>>>>>
> >>>>>> It would be cleaner to provide dummy arch_remap() for !__HAVE_ARCH_REMAP
> >>>>>> in some generic header.
> >>>>>
> >>>>> The idea was to not impact all the architectures as arch_unmap(),
> >>>>> arch_dup_mmap() or arch_exit_mmap() implies.
> >>>>>
> >>>>> I look at the headers where such a dummy arch_remap could be put but I
> >>>>> can't figure out one which will not impact all the architecture.
> >>>>> What about defining a dummy service earlier in mm/remap.c in the case
> >>>>> __HAVE_ARCH_REMAP is not defined ?
> >>>>> Something like :
> >>>>> #ifndef __HAVE_ARCH_REMAP
> >>>>> static inline void void arch_remap(struct mm_struct *mm,
> >>>>> unsigned long old_start,
> >>>>> unsigned long old_end,
> >>>>> unsigned long new_start,
> >>>>> unsigned long new_end)
> >>>>> {
> >>>>> }
> >>>>> #endif
> >>>>
> >>>> Or just #define arch_remap(...) do { } while (0)
> >>>>
> >>>
> >>> I guessed you wanted the arch_remap() prototype to be exposed somewhere
> >>> in the code.
> >>>
> >>> To be honest, I can't find the benefit of defining a dummy arch_remap()
> >>> in mm/remap.c if __HAVE_ARCH_REMAP is not defined instead of calling it
> >>> in move_vma if __HAVE_ARCH_REMAP is defined.
> >>> Is it really what you want ?
> >>
> >> I think Kirill meant something like e.g. the arch_enter_lazy_mmu_mode()
> >> is implemented and called in mm/mremap.c -- the "generic" part is in the
> >> include/asm-generic/pgtable.h and those architectures willing to have
> >> their own implementation are in arch/$arch/...
> >>
> >> 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
> > <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> at the end as we do for <asm/pgtable.h>.
> > But that's outside the scope of the patchset, I guess.
> >
> > I don't see any better candidate for such dummy header. :-/
>
> Clearly, I'm not confortable with a rewrite of <asm/mmu_context.h> :(
>
> So what about this patch, is this v3 acceptable ?
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
--
Kirill A. Shutemov
next prev parent reply other threads:[~2015-04-13 14:27 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-13 9:56 [RESEND PATCH v3 0/2] Tracking user space vDSO remaping Laurent Dufour
2015-04-13 9:56 ` Laurent Dufour
2015-04-13 9:56 ` Laurent Dufour
2015-04-13 9:56 ` [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook Laurent Dufour
2015-04-13 9:56 ` Laurent Dufour
2015-04-13 9:56 ` Laurent Dufour
2015-04-13 11:58 ` Kirill A. Shutemov
2015-04-13 11:58 ` Kirill A. Shutemov
2015-04-13 11:58 ` Kirill A. Shutemov
2015-04-13 12:41 ` Laurent Dufour
2015-04-13 12:41 ` Laurent Dufour
2015-04-13 12:41 ` Laurent Dufour
2015-04-13 13:13 ` Kirill A. Shutemov
2015-04-13 13:13 ` Kirill A. Shutemov
2015-04-13 13:13 ` Kirill A. Shutemov
2015-04-13 13:21 ` Laurent Dufour
2015-04-13 13:21 ` Laurent Dufour
2015-04-13 13:21 ` Laurent Dufour
2015-04-13 13:35 ` Pavel Emelyanov
2015-04-13 13:35 ` Pavel Emelyanov
2015-04-13 13:35 ` Pavel Emelyanov
2015-04-13 14:02 ` Kirill A. Shutemov
2015-04-13 14:02 ` Kirill A. Shutemov
2015-04-13 14:02 ` Kirill A. Shutemov
2015-04-13 14:11 ` Laurent Dufour
2015-04-13 14:11 ` Laurent Dufour
2015-04-13 14:11 ` Laurent Dufour
2015-04-13 14:26 ` Kirill A. Shutemov [this message]
2015-04-13 14:26 ` Kirill A. Shutemov
2015-04-13 14:26 ` Kirill A. Shutemov
2015-04-13 14:32 ` Pavel Emelyanov
2015-04-13 14:32 ` Pavel Emelyanov
2015-04-13 14:32 ` Pavel Emelyanov
2015-04-13 15:27 ` Laurent Dufour
2015-04-13 15:27 ` Laurent Dufour
2015-04-13 15:27 ` Laurent Dufour
2015-04-13 20:59 ` Andrew Morton
2015-04-13 20:59 ` Andrew Morton
2015-04-13 20:59 ` Andrew Morton
2015-04-14 9:26 ` Laurent Dufour
2015-04-14 9:26 ` Laurent Dufour
2015-04-14 9:26 ` Laurent Dufour
2015-04-14 19:38 ` Andrew Morton
2015-04-14 19:38 ` Andrew Morton
2015-04-14 19:38 ` Andrew Morton
2015-04-15 11:57 ` Laurent Dufour
2015-04-15 11:57 ` Laurent Dufour
2015-04-15 11:57 ` Laurent Dufour
2015-04-15 14:16 ` [PATCH v5 0/3] Tracking user space vDSO remaping Laurent Dufour
2015-04-15 14:16 ` Laurent Dufour
2015-04-15 14:16 ` Laurent Dufour
2015-04-15 14:16 ` [PATCH v5 1/3] mm: New mm hook framework Laurent Dufour
2015-04-15 14:16 ` Laurent Dufour
2015-04-15 14:16 ` Laurent Dufour
2015-04-15 14:16 ` [PATCH v5 2/3] mm: New arch_remap hook Laurent Dufour
2015-04-15 14:16 ` Laurent Dufour
2015-04-15 14:16 ` Laurent Dufour
2015-04-15 14:16 ` [PATCH v5 3/3] powerpc/mm: Tracking vDSO remap Laurent Dufour
2015-04-15 14:16 ` Laurent Dufour
2015-04-15 14:16 ` Laurent Dufour
2015-04-13 9:56 ` [RESEND PATCH v3 2/2] " Laurent Dufour
2015-04-13 9:56 ` Laurent Dufour
2015-04-13 9:56 ` Laurent Dufour
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150413142655.GA14646@node.dhcp.inet.fi \
--to=kirill@shutemov.name \
--cc=akpm@linux-foundation.org \
--cc=cov@codeaurora.org \
--cc=criu@openvz.org \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=ldufour@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=paulus@samba.org \
--cc=riel@redhat.com \
--cc=xemul@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.