[PATCH 0/2] Tracking user space vDSO remaping

[PATCH 0/2] Tracking user space vDSO remaping

[Laurent Dufour]

CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.

However some architectures like powerpc are keeping a reference to the vDSO
base address to build the signal return stack frame by calling the vDSO
sigreturn service. So once the vDSO has been moved, this reference is no
more valid and the signal frame built later are not usable.

This patch serie is introducing a new mm hook 'arch_remap' which is called
when mremap is done and the mm lock still 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      |  6 ++++++
 arch/um/include/asm/mmu_context.h        |  5 +++++
 arch/unicore32/include/asm/mmu_context.h |  6 ++++++
 arch/x86/include/asm/mmu_context.h       |  6 ++++++
 include/asm-generic/mm_hooks.h           |  6 ++++++
 mm/mremap.c                              |  9 ++++++--
 7 files changed, 70 insertions(+), 3 deletions(-)

-- 
1.9.1

[PATCH 0/2] Tracking user space vDSO remaping

[Laurent Dufour]

CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.

However some architectures like powerpc are keeping a reference to the vDSO
base address to build the signal return stack frame by calling the vDSO
sigreturn service. So once the vDSO has been moved, this reference is no
more valid and the signal frame built later are not usable.

This patch serie is introducing a new mm hook 'arch_remap' which is called
when mremap is done and the mm lock still 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      |  6 ++++++
 arch/um/include/asm/mmu_context.h        |  5 +++++
 arch/unicore32/include/asm/mmu_context.h |  6 ++++++
 arch/x86/include/asm/mmu_context.h       |  6 ++++++
 include/asm-generic/mm_hooks.h           |  6 ++++++
 mm/mremap.c                              |  9 ++++++--
 7 files changed, 70 insertions(+), 3 deletions(-)

-- 
1.9.1

[PATCH 0/2] Tracking user space vDSO remaping

[Laurent Dufour]

CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.

However some architectures like powerpc are keeping a reference to the vDSO
base address to build the signal return stack frame by calling the vDSO
sigreturn service. So once the vDSO has been moved, this reference is no
more valid and the signal frame built later are not usable.

This patch serie is introducing a new mm hook 'arch_remap' which is called
when mremap is done and the mm lock still 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      |  6 ++++++
 arch/um/include/asm/mmu_context.h        |  5 +++++
 arch/unicore32/include/asm/mmu_context.h |  6 ++++++
 arch/x86/include/asm/mmu_context.h       |  6 ++++++
 include/asm-generic/mm_hooks.h           |  6 ++++++
 mm/mremap.c                              |  9 ++++++--
 7 files changed, 70 insertions(+), 3 deletions(-)

-- 
1.9.1

--
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>

[PATCH 1/2] mm: Introducing arch_remap hook

[Laurent Dufour]

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).

To no break 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 <ldufour@linux.vnet.ibm.com>
---
 arch/s390/include/asm/mmu_context.h      | 6 ++++++
 arch/um/include/asm/mmu_context.h        | 5 +++++
 arch/unicore32/include/asm/mmu_context.h | 6 ++++++
 arch/x86/include/asm/mmu_context.h       | 6 ++++++
 include/asm-generic/mm_hooks.h           | 6 ++++++
 mm/mremap.c                              | 9 +++++++--
 6 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/arch/s390/include/asm/mmu_context.h b/arch/s390/include/asm/mmu_context.h
index 8fb3802f8fad..ddd861a490ba 100644
--- a/arch/s390/include/asm/mmu_context.h
+++ b/arch/s390/include/asm/mmu_context.h
@@ -131,4 +131,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 {
 }
 
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
+
 #endif /* __S390_MMU_CONTEXT_H */
diff --git a/arch/um/include/asm/mmu_context.h b/arch/um/include/asm/mmu_context.h
index 941527e507f7..f499b017c1f9 100644
--- a/arch/um/include/asm/mmu_context.h
+++ b/arch/um/include/asm/mmu_context.h
@@ -27,6 +27,11 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 				     struct vm_area_struct *vma)
 {
 }
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
 /*
  * end asm-generic/mm_hooks.h functions
  */
diff --git a/arch/unicore32/include/asm/mmu_context.h b/arch/unicore32/include/asm/mmu_context.h
index 1cb5220afaf9..39a0a553172e 100644
--- a/arch/unicore32/include/asm/mmu_context.h
+++ b/arch/unicore32/include/asm/mmu_context.h
@@ -97,4 +97,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 {
 }
 
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
+
 #endif
diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
index 883f6b933fa4..75cb71f4be1e 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -172,4 +172,10 @@ static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
 		mpx_notify_unmap(mm, vma, start, end);
 }
 
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
+
 #endif /* _ASM_X86_MMU_CONTEXT_H */
diff --git a/include/asm-generic/mm_hooks.h b/include/asm-generic/mm_hooks.h
index 866aa461efa5..e507f4783a5b 100644
--- a/include/asm-generic/mm_hooks.h
+++ b/include/asm-generic/mm_hooks.h
@@ -26,4 +26,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 {
 }
 
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
+
 #endif	/* _ASM_GENERIC_MM_HOOKS_H */
diff --git a/mm/mremap.c b/mm/mremap.c
index 57dadc025c64..6a409ca09425 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,8 +287,12 @@ 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)
-		vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+	} else {
+		if (vma->vm_file && vma->vm_file->f_op->mremap)
+			vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+		arch_remap(mm, old_addr, old_addr+old_len,
+			   new_addr, new_addr+new_len);
+	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */
 	if (vm_flags & VM_ACCOUNT) {
-- 
1.9.1

[PATCH 1/2] mm: Introducing arch_remap hook

[Laurent Dufour]

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).

To no break 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 <ldufour@linux.vnet.ibm.com>
---
 arch/s390/include/asm/mmu_context.h      | 6 ++++++
 arch/um/include/asm/mmu_context.h        | 5 +++++
 arch/unicore32/include/asm/mmu_context.h | 6 ++++++
 arch/x86/include/asm/mmu_context.h       | 6 ++++++
 include/asm-generic/mm_hooks.h           | 6 ++++++
 mm/mremap.c                              | 9 +++++++--
 6 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/arch/s390/include/asm/mmu_context.h b/arch/s390/include/asm/mmu_context.h
index 8fb3802f8fad..ddd861a490ba 100644
--- a/arch/s390/include/asm/mmu_context.h
+++ b/arch/s390/include/asm/mmu_context.h
@@ -131,4 +131,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 {
 }
 
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
+
 #endif /* __S390_MMU_CONTEXT_H */
diff --git a/arch/um/include/asm/mmu_context.h b/arch/um/include/asm/mmu_context.h
index 941527e507f7..f499b017c1f9 100644
--- a/arch/um/include/asm/mmu_context.h
+++ b/arch/um/include/asm/mmu_context.h
@@ -27,6 +27,11 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 				     struct vm_area_struct *vma)
 {
 }
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
 /*
  * end asm-generic/mm_hooks.h functions
  */
diff --git a/arch/unicore32/include/asm/mmu_context.h b/arch/unicore32/include/asm/mmu_context.h
index 1cb5220afaf9..39a0a553172e 100644
--- a/arch/unicore32/include/asm/mmu_context.h
+++ b/arch/unicore32/include/asm/mmu_context.h
@@ -97,4 +97,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 {
 }
 
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
+
 #endif
diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
index 883f6b933fa4..75cb71f4be1e 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -172,4 +172,10 @@ static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
 		mpx_notify_unmap(mm, vma, start, end);
 }
 
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
+
 #endif /* _ASM_X86_MMU_CONTEXT_H */
diff --git a/include/asm-generic/mm_hooks.h b/include/asm-generic/mm_hooks.h
index 866aa461efa5..e507f4783a5b 100644
--- a/include/asm-generic/mm_hooks.h
+++ b/include/asm-generic/mm_hooks.h
@@ -26,4 +26,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 {
 }
 
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
+
 #endif	/* _ASM_GENERIC_MM_HOOKS_H */
diff --git a/mm/mremap.c b/mm/mremap.c
index 57dadc025c64..6a409ca09425 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,8 +287,12 @@ 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)
-		vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+	} else {
+		if (vma->vm_file && vma->vm_file->f_op->mremap)
+			vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+		arch_remap(mm, old_addr, old_addr+old_len,
+			   new_addr, new_addr+new_len);
+	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */
 	if (vm_flags & VM_ACCOUNT) {
-- 
1.9.1

[PATCH 1/2] mm: Introducing arch_remap hook

[Laurent Dufour]

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).

To no break 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 <ldufour@linux.vnet.ibm.com>
---
 arch/s390/include/asm/mmu_context.h      | 6 ++++++
 arch/um/include/asm/mmu_context.h        | 5 +++++
 arch/unicore32/include/asm/mmu_context.h | 6 ++++++
 arch/x86/include/asm/mmu_context.h       | 6 ++++++
 include/asm-generic/mm_hooks.h           | 6 ++++++
 mm/mremap.c                              | 9 +++++++--
 6 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/arch/s390/include/asm/mmu_context.h b/arch/s390/include/asm/mmu_context.h
index 8fb3802f8fad..ddd861a490ba 100644
--- a/arch/s390/include/asm/mmu_context.h
+++ b/arch/s390/include/asm/mmu_context.h
@@ -131,4 +131,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 {
 }
 
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
+
 #endif /* __S390_MMU_CONTEXT_H */
diff --git a/arch/um/include/asm/mmu_context.h b/arch/um/include/asm/mmu_context.h
index 941527e507f7..f499b017c1f9 100644
--- a/arch/um/include/asm/mmu_context.h
+++ b/arch/um/include/asm/mmu_context.h
@@ -27,6 +27,11 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 				     struct vm_area_struct *vma)
 {
 }
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
 /*
  * end asm-generic/mm_hooks.h functions
  */
diff --git a/arch/unicore32/include/asm/mmu_context.h b/arch/unicore32/include/asm/mmu_context.h
index 1cb5220afaf9..39a0a553172e 100644
--- a/arch/unicore32/include/asm/mmu_context.h
+++ b/arch/unicore32/include/asm/mmu_context.h
@@ -97,4 +97,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 {
 }
 
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
+
 #endif
diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
index 883f6b933fa4..75cb71f4be1e 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -172,4 +172,10 @@ static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
 		mpx_notify_unmap(mm, vma, start, end);
 }
 
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
+
 #endif /* _ASM_X86_MMU_CONTEXT_H */
diff --git a/include/asm-generic/mm_hooks.h b/include/asm-generic/mm_hooks.h
index 866aa461efa5..e507f4783a5b 100644
--- a/include/asm-generic/mm_hooks.h
+++ b/include/asm-generic/mm_hooks.h
@@ -26,4 +26,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 {
 }
 
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+}
+
 #endif	/* _ASM_GENERIC_MM_HOOKS_H */
diff --git a/mm/mremap.c b/mm/mremap.c
index 57dadc025c64..6a409ca09425 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,8 +287,12 @@ 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)
-		vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+	} else {
+		if (vma->vm_file && vma->vm_file->f_op->mremap)
+			vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+		arch_remap(mm, old_addr, old_addr+old_len,
+			   new_addr, new_addr+new_len);
+	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */
 	if (vm_flags & VM_ACCOUNT) {
-- 
1.9.1

--
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>

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

[Richard Weinberger]

Am 20.03.2015 um 16:53 schrieb Laurent Dufour:
> 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).
> 
> To no break the build, this patch adds the empty hook definition to the
> architectures that were not using the generic hook's definition.

Just wanted to point out that I like that new hook as UserModeLinux can benefit from it.
UML has the concept of stub pages where the UML host process can inject commands to guest processes.
Currently we play nasty games in the TLB code to make all this work.
arch_unmap() could make this stuff more clear and less error prone.

Thanks,
//richard

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

[Richard Weinberger]

Am 20.03.2015 um 16:53 schrieb Laurent Dufour:
> 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).
> 
> To no break the build, this patch adds the empty hook definition to the
> architectures that were not using the generic hook's definition.

Just wanted to point out that I like that new hook as UserModeLinux can benefit from it.
UML has the concept of stub pages where the UML host process can inject commands to guest processes.
Currently we play nasty games in the TLB code to make all this work.
arch_unmap() could make this stuff more clear and less error prone.

Thanks,
//richard

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

[Richard Weinberger]

Am 20.03.2015 um 16:53 schrieb Laurent Dufour:
> 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).
> 
> To no break the build, this patch adds the empty hook definition to the
> architectures that were not using the generic hook's definition.

Just wanted to point out that I like that new hook as UserModeLinux can benefit from it.
UML has the concept of stub pages where the UML host process can inject commands to guest processes.
Currently we play nasty games in the TLB code to make all this work.
arch_unmap() could make this stuff more clear and less error prone.

Thanks,
//richard

--
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>

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

[Ingo Molnar]

* Laurent Dufour <ldufour@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, and is called before the old area is unmapped (and the
> arch_unmap hook is called).
> 
> To no break 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 <ldufour@linux.vnet.ibm.com>
> ---
>  arch/s390/include/asm/mmu_context.h      | 6 ++++++
>  arch/um/include/asm/mmu_context.h        | 5 +++++
>  arch/unicore32/include/asm/mmu_context.h | 6 ++++++
>  arch/x86/include/asm/mmu_context.h       | 6 ++++++
>  include/asm-generic/mm_hooks.h           | 6 ++++++
>  mm/mremap.c                              | 9 +++++++--
>  6 files changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/s390/include/asm/mmu_context.h b/arch/s390/include/asm/mmu_context.h
> index 8fb3802f8fad..ddd861a490ba 100644
> --- a/arch/s390/include/asm/mmu_context.h
> +++ b/arch/s390/include/asm/mmu_context.h
> @@ -131,4 +131,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>  {
>  }
>  
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +}
> +
>  #endif /* __S390_MMU_CONTEXT_H */
> diff --git a/arch/um/include/asm/mmu_context.h b/arch/um/include/asm/mmu_context.h
> index 941527e507f7..f499b017c1f9 100644
> --- a/arch/um/include/asm/mmu_context.h
> +++ b/arch/um/include/asm/mmu_context.h
> @@ -27,6 +27,11 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>  				     struct vm_area_struct *vma)
>  {
>  }
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +}
>  /*
>   * end asm-generic/mm_hooks.h functions
>   */
> diff --git a/arch/unicore32/include/asm/mmu_context.h b/arch/unicore32/include/asm/mmu_context.h
> index 1cb5220afaf9..39a0a553172e 100644
> --- a/arch/unicore32/include/asm/mmu_context.h
> +++ b/arch/unicore32/include/asm/mmu_context.h
> @@ -97,4 +97,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>  {
>  }
>  
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +}
> +
>  #endif
> diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
> index 883f6b933fa4..75cb71f4be1e 100644
> --- a/arch/x86/include/asm/mmu_context.h
> +++ b/arch/x86/include/asm/mmu_context.h
> @@ -172,4 +172,10 @@ static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
>  		mpx_notify_unmap(mm, vma, start, end);
>  }
>  
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +}
> +
>  #endif /* _ASM_X86_MMU_CONTEXT_H */

So instead of spreading these empty prototypes around mmu_context.h 
files, why not add something like this to the PPC definition:

 #define __HAVE_ARCH_REMAP

and define the empty prototype for everyone else? It's a bit like how 
the __HAVE_ARCH_PTEP_* namespace works.

That should shrink this patch considerably.

Thanks,

	Ingo

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

[Ingo Molnar]

* Laurent Dufour <ldufour@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, and is called before the old area is unmapped (and the
> arch_unmap hook is called).
> 
> To no break 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 <ldufour@linux.vnet.ibm.com>
> ---
>  arch/s390/include/asm/mmu_context.h      | 6 ++++++
>  arch/um/include/asm/mmu_context.h        | 5 +++++
>  arch/unicore32/include/asm/mmu_context.h | 6 ++++++
>  arch/x86/include/asm/mmu_context.h       | 6 ++++++
>  include/asm-generic/mm_hooks.h           | 6 ++++++
>  mm/mremap.c                              | 9 +++++++--
>  6 files changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/s390/include/asm/mmu_context.h b/arch/s390/include/asm/mmu_context.h
> index 8fb3802f8fad..ddd861a490ba 100644
> --- a/arch/s390/include/asm/mmu_context.h
> +++ b/arch/s390/include/asm/mmu_context.h
> @@ -131,4 +131,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>  {
>  }
>  
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +}
> +
>  #endif /* __S390_MMU_CONTEXT_H */
> diff --git a/arch/um/include/asm/mmu_context.h b/arch/um/include/asm/mmu_context.h
> index 941527e507f7..f499b017c1f9 100644
> --- a/arch/um/include/asm/mmu_context.h
> +++ b/arch/um/include/asm/mmu_context.h
> @@ -27,6 +27,11 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>  				     struct vm_area_struct *vma)
>  {
>  }
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +}
>  /*
>   * end asm-generic/mm_hooks.h functions
>   */
> diff --git a/arch/unicore32/include/asm/mmu_context.h b/arch/unicore32/include/asm/mmu_context.h
> index 1cb5220afaf9..39a0a553172e 100644
> --- a/arch/unicore32/include/asm/mmu_context.h
> +++ b/arch/unicore32/include/asm/mmu_context.h
> @@ -97,4 +97,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>  {
>  }
>  
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +}
> +
>  #endif
> diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
> index 883f6b933fa4..75cb71f4be1e 100644
> --- a/arch/x86/include/asm/mmu_context.h
> +++ b/arch/x86/include/asm/mmu_context.h
> @@ -172,4 +172,10 @@ static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
>  		mpx_notify_unmap(mm, vma, start, end);
>  }
>  
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +}
> +
>  #endif /* _ASM_X86_MMU_CONTEXT_H */

So instead of spreading these empty prototypes around mmu_context.h 
files, why not add something like this to the PPC definition:

 #define __HAVE_ARCH_REMAP

and define the empty prototype for everyone else? It's a bit like how 
the __HAVE_ARCH_PTEP_* namespace works.

That should shrink this patch considerably.

Thanks,

	Ingo

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

[Ingo Molnar]

* Laurent Dufour <ldufour@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, and is called before the old area is unmapped (and the
> arch_unmap hook is called).
> 
> To no break 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 <ldufour@linux.vnet.ibm.com>
> ---
>  arch/s390/include/asm/mmu_context.h      | 6 ++++++
>  arch/um/include/asm/mmu_context.h        | 5 +++++
>  arch/unicore32/include/asm/mmu_context.h | 6 ++++++
>  arch/x86/include/asm/mmu_context.h       | 6 ++++++
>  include/asm-generic/mm_hooks.h           | 6 ++++++
>  mm/mremap.c                              | 9 +++++++--
>  6 files changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/s390/include/asm/mmu_context.h b/arch/s390/include/asm/mmu_context.h
> index 8fb3802f8fad..ddd861a490ba 100644
> --- a/arch/s390/include/asm/mmu_context.h
> +++ b/arch/s390/include/asm/mmu_context.h
> @@ -131,4 +131,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>  {
>  }
>  
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +}
> +
>  #endif /* __S390_MMU_CONTEXT_H */
> diff --git a/arch/um/include/asm/mmu_context.h b/arch/um/include/asm/mmu_context.h
> index 941527e507f7..f499b017c1f9 100644
> --- a/arch/um/include/asm/mmu_context.h
> +++ b/arch/um/include/asm/mmu_context.h
> @@ -27,6 +27,11 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>  				     struct vm_area_struct *vma)
>  {
>  }
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +}
>  /*
>   * end asm-generic/mm_hooks.h functions
>   */
> diff --git a/arch/unicore32/include/asm/mmu_context.h b/arch/unicore32/include/asm/mmu_context.h
> index 1cb5220afaf9..39a0a553172e 100644
> --- a/arch/unicore32/include/asm/mmu_context.h
> +++ b/arch/unicore32/include/asm/mmu_context.h
> @@ -97,4 +97,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>  {
>  }
>  
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +}
> +
>  #endif
> diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
> index 883f6b933fa4..75cb71f4be1e 100644
> --- a/arch/x86/include/asm/mmu_context.h
> +++ b/arch/x86/include/asm/mmu_context.h
> @@ -172,4 +172,10 @@ static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
>  		mpx_notify_unmap(mm, vma, start, end);
>  }
>  
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +}
> +
>  #endif /* _ASM_X86_MMU_CONTEXT_H */

So instead of spreading these empty prototypes around mmu_context.h 
files, why not add something like this to the PPC definition:

 #define __HAVE_ARCH_REMAP

and define the empty prototype for everyone else? It's a bit like how 
the __HAVE_ARCH_PTEP_* namespace works.

That should shrink this patch considerably.

Thanks,

	Ingo

--
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>

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

[Laurent Dufour]

On 23/03/2015 09:52, Ingo Molnar wrote:
> 
> * Laurent Dufour <ldufour@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, and is called before the old area is unmapped (and the
>> arch_unmap hook is called).
>>
>> To no break 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 <ldufour@linux.vnet.ibm.com>
>> ---
>>  arch/s390/include/asm/mmu_context.h      | 6 ++++++
>>  arch/um/include/asm/mmu_context.h        | 5 +++++
>>  arch/unicore32/include/asm/mmu_context.h | 6 ++++++
>>  arch/x86/include/asm/mmu_context.h       | 6 ++++++
>>  include/asm-generic/mm_hooks.h           | 6 ++++++
>>  mm/mremap.c                              | 9 +++++++--
>>  6 files changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/s390/include/asm/mmu_context.h b/arch/s390/include/asm/mmu_context.h
>> index 8fb3802f8fad..ddd861a490ba 100644
>> --- a/arch/s390/include/asm/mmu_context.h
>> +++ b/arch/s390/include/asm/mmu_context.h
>> @@ -131,4 +131,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>>  {
>>  }
>>  
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +}
>> +
>>  #endif /* __S390_MMU_CONTEXT_H */
>> diff --git a/arch/um/include/asm/mmu_context.h b/arch/um/include/asm/mmu_context.h
>> index 941527e507f7..f499b017c1f9 100644
>> --- a/arch/um/include/asm/mmu_context.h
>> +++ b/arch/um/include/asm/mmu_context.h
>> @@ -27,6 +27,11 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>>  				     struct vm_area_struct *vma)
>>  {
>>  }
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +}
>>  /*
>>   * end asm-generic/mm_hooks.h functions
>>   */
>> diff --git a/arch/unicore32/include/asm/mmu_context.h b/arch/unicore32/include/asm/mmu_context.h
>> index 1cb5220afaf9..39a0a553172e 100644
>> --- a/arch/unicore32/include/asm/mmu_context.h
>> +++ b/arch/unicore32/include/asm/mmu_context.h
>> @@ -97,4 +97,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>>  {
>>  }
>>  
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +}
>> +
>>  #endif
>> diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
>> index 883f6b933fa4..75cb71f4be1e 100644
>> --- a/arch/x86/include/asm/mmu_context.h
>> +++ b/arch/x86/include/asm/mmu_context.h
>> @@ -172,4 +172,10 @@ static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
>>  		mpx_notify_unmap(mm, vma, start, end);
>>  }
>>  
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +}
>> +
>>  #endif /* _ASM_X86_MMU_CONTEXT_H */
> 
> So instead of spreading these empty prototypes around mmu_context.h 
> files, why not add something like this to the PPC definition:
> 
>  #define __HAVE_ARCH_REMAP
> 
> and define the empty prototype for everyone else? It's a bit like how 
> the __HAVE_ARCH_PTEP_* namespace works.
> 
> That should shrink this patch considerably.

My idea was to mimic the MMU hook's definition. This new hook is in the
continuity of what have been done for arch_dup_mmap, arch_exit_mmap,
arch_unmap and arch_bprm_mm_init.

Do you think that there is a need to make this one in another way ?

Thanks,
Laurent.

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

[Laurent Dufour]

On 23/03/2015 09:52, Ingo Molnar wrote:
> 
> * Laurent Dufour <ldufour@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, and is called before the old area is unmapped (and the
>> arch_unmap hook is called).
>>
>> To no break 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 <ldufour@linux.vnet.ibm.com>
>> ---
>>  arch/s390/include/asm/mmu_context.h      | 6 ++++++
>>  arch/um/include/asm/mmu_context.h        | 5 +++++
>>  arch/unicore32/include/asm/mmu_context.h | 6 ++++++
>>  arch/x86/include/asm/mmu_context.h       | 6 ++++++
>>  include/asm-generic/mm_hooks.h           | 6 ++++++
>>  mm/mremap.c                              | 9 +++++++--
>>  6 files changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/s390/include/asm/mmu_context.h b/arch/s390/include/asm/mmu_context.h
>> index 8fb3802f8fad..ddd861a490ba 100644
>> --- a/arch/s390/include/asm/mmu_context.h
>> +++ b/arch/s390/include/asm/mmu_context.h
>> @@ -131,4 +131,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>>  {
>>  }
>>  
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +}
>> +
>>  #endif /* __S390_MMU_CONTEXT_H */
>> diff --git a/arch/um/include/asm/mmu_context.h b/arch/um/include/asm/mmu_context.h
>> index 941527e507f7..f499b017c1f9 100644
>> --- a/arch/um/include/asm/mmu_context.h
>> +++ b/arch/um/include/asm/mmu_context.h
>> @@ -27,6 +27,11 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>>  				     struct vm_area_struct *vma)
>>  {
>>  }
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +}
>>  /*
>>   * end asm-generic/mm_hooks.h functions
>>   */
>> diff --git a/arch/unicore32/include/asm/mmu_context.h b/arch/unicore32/include/asm/mmu_context.h
>> index 1cb5220afaf9..39a0a553172e 100644
>> --- a/arch/unicore32/include/asm/mmu_context.h
>> +++ b/arch/unicore32/include/asm/mmu_context.h
>> @@ -97,4 +97,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>>  {
>>  }
>>  
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +}
>> +
>>  #endif
>> diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
>> index 883f6b933fa4..75cb71f4be1e 100644
>> --- a/arch/x86/include/asm/mmu_context.h
>> +++ b/arch/x86/include/asm/mmu_context.h
>> @@ -172,4 +172,10 @@ static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
>>  		mpx_notify_unmap(mm, vma, start, end);
>>  }
>>  
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +}
>> +
>>  #endif /* _ASM_X86_MMU_CONTEXT_H */
> 
> So instead of spreading these empty prototypes around mmu_context.h 
> files, why not add something like this to the PPC definition:
> 
>  #define __HAVE_ARCH_REMAP
> 
> and define the empty prototype for everyone else? It's a bit like how 
> the __HAVE_ARCH_PTEP_* namespace works.
> 
> That should shrink this patch considerably.

My idea was to mimic the MMU hook's definition. This new hook is in the
continuity of what have been done for arch_dup_mmap, arch_exit_mmap,
arch_unmap and arch_bprm_mm_init.

Do you think that there is a need to make this one in another way ?

Thanks,
Laurent.

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

[Laurent Dufour]

On 23/03/2015 09:52, Ingo Molnar wrote:
> 
> * Laurent Dufour <ldufour@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, and is called before the old area is unmapped (and the
>> arch_unmap hook is called).
>>
>> To no break 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 <ldufour@linux.vnet.ibm.com>
>> ---
>>  arch/s390/include/asm/mmu_context.h      | 6 ++++++
>>  arch/um/include/asm/mmu_context.h        | 5 +++++
>>  arch/unicore32/include/asm/mmu_context.h | 6 ++++++
>>  arch/x86/include/asm/mmu_context.h       | 6 ++++++
>>  include/asm-generic/mm_hooks.h           | 6 ++++++
>>  mm/mremap.c                              | 9 +++++++--
>>  6 files changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/s390/include/asm/mmu_context.h b/arch/s390/include/asm/mmu_context.h
>> index 8fb3802f8fad..ddd861a490ba 100644
>> --- a/arch/s390/include/asm/mmu_context.h
>> +++ b/arch/s390/include/asm/mmu_context.h
>> @@ -131,4 +131,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>>  {
>>  }
>>  
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +}
>> +
>>  #endif /* __S390_MMU_CONTEXT_H */
>> diff --git a/arch/um/include/asm/mmu_context.h b/arch/um/include/asm/mmu_context.h
>> index 941527e507f7..f499b017c1f9 100644
>> --- a/arch/um/include/asm/mmu_context.h
>> +++ b/arch/um/include/asm/mmu_context.h
>> @@ -27,6 +27,11 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>>  				     struct vm_area_struct *vma)
>>  {
>>  }
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +}
>>  /*
>>   * end asm-generic/mm_hooks.h functions
>>   */
>> diff --git a/arch/unicore32/include/asm/mmu_context.h b/arch/unicore32/include/asm/mmu_context.h
>> index 1cb5220afaf9..39a0a553172e 100644
>> --- a/arch/unicore32/include/asm/mmu_context.h
>> +++ b/arch/unicore32/include/asm/mmu_context.h
>> @@ -97,4 +97,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>>  {
>>  }
>>  
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +}
>> +
>>  #endif
>> diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
>> index 883f6b933fa4..75cb71f4be1e 100644
>> --- a/arch/x86/include/asm/mmu_context.h
>> +++ b/arch/x86/include/asm/mmu_context.h
>> @@ -172,4 +172,10 @@ static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
>>  		mpx_notify_unmap(mm, vma, start, end);
>>  }
>>  
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +}
>> +
>>  #endif /* _ASM_X86_MMU_CONTEXT_H */
> 
> So instead of spreading these empty prototypes around mmu_context.h 
> files, why not add something like this to the PPC definition:
> 
>  #define __HAVE_ARCH_REMAP
> 
> and define the empty prototype for everyone else? It's a bit like how 
> the __HAVE_ARCH_PTEP_* namespace works.
> 
> That should shrink this patch considerably.

My idea was to mimic the MMU hook's definition. This new hook is in the
continuity of what have been done for arch_dup_mmap, arch_exit_mmap,
arch_unmap and arch_bprm_mm_init.

Do you think that there is a need to make this one in another way ?

Thanks,
Laurent.

--
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>

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

[Laurent Dufour]

CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.

However some architectures like powerpc are keeping a reference to the vDSO
base address to build the signal return stack frame by calling the vDSO
sigreturn service. So once the vDSO has been moved, this reference is no
more valid and the signal frame built later are not usable.

This patch serie is introducing a new mm hook 'arch_remap' which is called
when mremap is done and the mm lock still 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):
  mm: Introducing arch_remap hook
  powerpc/mm: Tracking vDSO remap

 arch/powerpc/include/asm/mmu_context.h | 36 +++++++++++++++++++++++++++++++++-
 mm/mremap.c                            | 11 +++++++++--
 2 files changed, 44 insertions(+), 3 deletions(-)

-- 
1.9.1

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

[Laurent Dufour]

CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.

However some architectures like powerpc are keeping a reference to the vDSO
base address to build the signal return stack frame by calling the vDSO
sigreturn service. So once the vDSO has been moved, this reference is no
more valid and the signal frame built later are not usable.

This patch serie is introducing a new mm hook 'arch_remap' which is called
when mremap is done and the mm lock still 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):
  mm: Introducing arch_remap hook
  powerpc/mm: Tracking vDSO remap

 arch/powerpc/include/asm/mmu_context.h | 36 +++++++++++++++++++++++++++++++++-
 mm/mremap.c                            | 11 +++++++++--
 2 files changed, 44 insertions(+), 3 deletions(-)

-- 
1.9.1

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

[Laurent Dufour]

CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.

However some architectures like powerpc are keeping a reference to the vDSO
base address to build the signal return stack frame by calling the vDSO
sigreturn service. So once the vDSO has been moved, this reference is no
more valid and the signal frame built later are not usable.

This patch serie is introducing a new mm hook 'arch_remap' which is called
when mremap is done and the mm lock still 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):
  mm: Introducing arch_remap hook
  powerpc/mm: Tracking vDSO remap

 arch/powerpc/include/asm/mmu_context.h | 36 +++++++++++++++++++++++++++++++++-
 mm/mremap.c                            | 11 +++++++++--
 2 files changed, 44 insertions(+), 3 deletions(-)

-- 
1.9.1

--
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>

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

[Laurent Dufour]

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>
---
 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 @@
 
 #include <asm/cacheflush.h>
 #include <asm/tlbflush.h>
+#include <asm/mmu_context.h>
 
 #include "internal.h"
 
@@ -286,8 +287,14 @@ 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)
-		vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+	} else {
+		if (vma->vm_file && vma->vm_file->f_op->mremap)
+			vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+#ifdef __HAVE_ARCH_REMAP
+		arch_remap(mm, old_addr, old_addr+old_len,
+			   new_addr, new_addr+new_len);
+#endif
+	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */
 	if (vm_flags & VM_ACCOUNT) {
-- 
1.9.1

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

[Laurent Dufour]

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>
---
 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 @@
 
 #include <asm/cacheflush.h>
 #include <asm/tlbflush.h>
+#include <asm/mmu_context.h>
 
 #include "internal.h"
 
@@ -286,8 +287,14 @@ 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)
-		vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+	} else {
+		if (vma->vm_file && vma->vm_file->f_op->mremap)
+			vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+#ifdef __HAVE_ARCH_REMAP
+		arch_remap(mm, old_addr, old_addr+old_len,
+			   new_addr, new_addr+new_len);
+#endif
+	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */
 	if (vm_flags & VM_ACCOUNT) {
-- 
1.9.1

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

[Laurent Dufour]

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>
---
 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 @@
 
 #include <asm/cacheflush.h>
 #include <asm/tlbflush.h>
+#include <asm/mmu_context.h>
 
 #include "internal.h"
 
@@ -286,8 +287,14 @@ 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)
-		vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+	} else {
+		if (vma->vm_file && vma->vm_file->f_op->mremap)
+			vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+#ifdef __HAVE_ARCH_REMAP
+		arch_remap(mm, old_addr, old_addr+old_len,
+			   new_addr, new_addr+new_len);
+#endif
+	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */
 	if (vm_flags & VM_ACCOUNT) {
-- 
1.9.1

--
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>

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

[Laurent Dufour]

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 the vDSO has been
moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.

Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
index 73382eba02dc..be5dca3f7826 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*
@@ -109,5 +108,40 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
 #endif
 }
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				 struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+static inline void arch_unmap(struct mm_struct *mm,
+			struct vm_area_struct *vma,
+			unsigned long start, unsigned long end)
+{
+	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
+		mm->context.vdso_base = 0;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	/*
+	 * mremap don't allow moving multiple vma so we can limit the check
+	 * to old_start == vdso_base.
+	 */
+	if (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
-- 
1.9.1

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

[Laurent Dufour]

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 the vDSO has been
moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.

Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
index 73382eba02dc..be5dca3f7826 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*
@@ -109,5 +108,40 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
 #endif
 }
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				 struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+static inline void arch_unmap(struct mm_struct *mm,
+			struct vm_area_struct *vma,
+			unsigned long start, unsigned long end)
+{
+	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
+		mm->context.vdso_base = 0;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	/*
+	 * mremap don't allow moving multiple vma so we can limit the check
+	 * to old_start == vdso_base.
+	 */
+	if (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
-- 
1.9.1

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

[Laurent Dufour]

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 the vDSO has been
moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.

Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
index 73382eba02dc..be5dca3f7826 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*
@@ -109,5 +108,40 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
 #endif
 }
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				 struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+static inline void arch_unmap(struct mm_struct *mm,
+			struct vm_area_struct *vma,
+			unsigned long start, unsigned long end)
+{
+	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
+		mm->context.vdso_base = 0;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	/*
+	 * mremap don't allow moving multiple vma so we can limit the check
+	 * to old_start == vdso_base.
+	 */
+	if (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
-- 
1.9.1

--
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>

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

[Ingo Molnar]

* Laurent Dufour <ldufour@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 the vDSO has been
> moved is not pointing to the new sigreturn address.
> 
> This patch handles vDSO remapping and unmapping.
> 
> Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
> index 73382eba02dc..be5dca3f7826 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -8,7 +8,6 @@
>  #include <linux/spinlock.h>
>  #include <asm/mmu.h>	
>  #include <asm/cputable.h>
> -#include <asm-generic/mm_hooks.h>
>  #include <asm/cputhreads.h>
>  
>  /*
> @@ -109,5 +108,40 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
>  #endif
>  }
>  
> +static inline void arch_dup_mmap(struct mm_struct *oldmm,
> +				 struct mm_struct *mm)
> +{
> +}
> +
> +static inline void arch_exit_mmap(struct mm_struct *mm)
> +{
> +}
> +
> +static inline void arch_unmap(struct mm_struct *mm,
> +			struct vm_area_struct *vma,
> +			unsigned long start, unsigned long end)
> +{
> +	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> +		mm->context.vdso_base = 0;
> +}
> +
> +static inline void arch_bprm_mm_init(struct mm_struct *mm,
> +				     struct vm_area_struct *vma)
> +{
> +}
> +
> +#define __HAVE_ARCH_REMAP
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +	/*
> +	 * mremap don't allow moving multiple vma so we can limit the check
> +	 * to old_start == vdso_base.

s/mremap don't allow moving multiple vma
  mremap() doesn't allow moving multiple vmas

right?

Thanks,

	Ingo

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

[Ingo Molnar]

* Laurent Dufour <ldufour@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 the vDSO has been
> moved is not pointing to the new sigreturn address.
> 
> This patch handles vDSO remapping and unmapping.
> 
> Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
> index 73382eba02dc..be5dca3f7826 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -8,7 +8,6 @@
>  #include <linux/spinlock.h>
>  #include <asm/mmu.h>	
>  #include <asm/cputable.h>
> -#include <asm-generic/mm_hooks.h>
>  #include <asm/cputhreads.h>
>  
>  /*
> @@ -109,5 +108,40 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
>  #endif
>  }
>  
> +static inline void arch_dup_mmap(struct mm_struct *oldmm,
> +				 struct mm_struct *mm)
> +{
> +}
> +
> +static inline void arch_exit_mmap(struct mm_struct *mm)
> +{
> +}
> +
> +static inline void arch_unmap(struct mm_struct *mm,
> +			struct vm_area_struct *vma,
> +			unsigned long start, unsigned long end)
> +{
> +	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> +		mm->context.vdso_base = 0;
> +}
> +
> +static inline void arch_bprm_mm_init(struct mm_struct *mm,
> +				     struct vm_area_struct *vma)
> +{
> +}
> +
> +#define __HAVE_ARCH_REMAP
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +	/*
> +	 * mremap don't allow moving multiple vma so we can limit the check
> +	 * to old_start == vdso_base.

s/mremap don't allow moving multiple vma
  mremap() doesn't allow moving multiple vmas

right?

Thanks,

	Ingo

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

[Ingo Molnar]

* Laurent Dufour <ldufour@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 the vDSO has been
> moved is not pointing to the new sigreturn address.
> 
> This patch handles vDSO remapping and unmapping.
> 
> Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
> index 73382eba02dc..be5dca3f7826 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -8,7 +8,6 @@
>  #include <linux/spinlock.h>
>  #include <asm/mmu.h>	
>  #include <asm/cputable.h>
> -#include <asm-generic/mm_hooks.h>
>  #include <asm/cputhreads.h>
>  
>  /*
> @@ -109,5 +108,40 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
>  #endif
>  }
>  
> +static inline void arch_dup_mmap(struct mm_struct *oldmm,
> +				 struct mm_struct *mm)
> +{
> +}
> +
> +static inline void arch_exit_mmap(struct mm_struct *mm)
> +{
> +}
> +
> +static inline void arch_unmap(struct mm_struct *mm,
> +			struct vm_area_struct *vma,
> +			unsigned long start, unsigned long end)
> +{
> +	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> +		mm->context.vdso_base = 0;
> +}
> +
> +static inline void arch_bprm_mm_init(struct mm_struct *mm,
> +				     struct vm_area_struct *vma)
> +{
> +}
> +
> +#define __HAVE_ARCH_REMAP
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +	/*
> +	 * mremap don't allow moving multiple vma so we can limit the check
> +	 * to old_start == vdso_base.

s/mremap don't allow moving multiple vma
  mremap() doesn't allow moving multiple vmas

right?

Thanks,

	Ingo

--
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>

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

[Laurent Dufour]

On 25/03/2015 13:11, Ingo Molnar wrote:
> 
> * Laurent Dufour <ldufour@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 the vDSO has been
>> moved is not pointing to the new sigreturn address.
>>
>> This patch handles vDSO remapping and unmapping.
>>
>> Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
>> index 73382eba02dc..be5dca3f7826 100644
>> --- a/arch/powerpc/include/asm/mmu_context.h
>> +++ b/arch/powerpc/include/asm/mmu_context.h
>> @@ -8,7 +8,6 @@
>>  #include <linux/spinlock.h>
>>  #include <asm/mmu.h>	
>>  #include <asm/cputable.h>
>> -#include <asm-generic/mm_hooks.h>
>>  #include <asm/cputhreads.h>
>>  
>>  /*
>> @@ -109,5 +108,40 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
>>  #endif
>>  }
>>  
>> +static inline void arch_dup_mmap(struct mm_struct *oldmm,
>> +				 struct mm_struct *mm)
>> +{
>> +}
>> +
>> +static inline void arch_exit_mmap(struct mm_struct *mm)
>> +{
>> +}
>> +
>> +static inline void arch_unmap(struct mm_struct *mm,
>> +			struct vm_area_struct *vma,
>> +			unsigned long start, unsigned long end)
>> +{
>> +	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
>> +		mm->context.vdso_base = 0;
>> +}
>> +
>> +static inline void arch_bprm_mm_init(struct mm_struct *mm,
>> +				     struct vm_area_struct *vma)
>> +{
>> +}
>> +
>> +#define __HAVE_ARCH_REMAP
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +	/*
>> +	 * mremap don't allow moving multiple vma so we can limit the check
>> +	 * to old_start == vdso_base.
> 
> s/mremap don't allow moving multiple vma
>   mremap() doesn't allow moving multiple vmas
> 
> right?

Sure you're right.

I'll provide a v3 fixing that comment.

Thanks,
Laurent.

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

[Laurent Dufour]

On 25/03/2015 13:11, Ingo Molnar wrote:
> 
> * Laurent Dufour <ldufour@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 the vDSO has been
>> moved is not pointing to the new sigreturn address.
>>
>> This patch handles vDSO remapping and unmapping.
>>
>> Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
>> index 73382eba02dc..be5dca3f7826 100644
>> --- a/arch/powerpc/include/asm/mmu_context.h
>> +++ b/arch/powerpc/include/asm/mmu_context.h
>> @@ -8,7 +8,6 @@
>>  #include <linux/spinlock.h>
>>  #include <asm/mmu.h>	
>>  #include <asm/cputable.h>
>> -#include <asm-generic/mm_hooks.h>
>>  #include <asm/cputhreads.h>
>>  
>>  /*
>> @@ -109,5 +108,40 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
>>  #endif
>>  }
>>  
>> +static inline void arch_dup_mmap(struct mm_struct *oldmm,
>> +				 struct mm_struct *mm)
>> +{
>> +}
>> +
>> +static inline void arch_exit_mmap(struct mm_struct *mm)
>> +{
>> +}
>> +
>> +static inline void arch_unmap(struct mm_struct *mm,
>> +			struct vm_area_struct *vma,
>> +			unsigned long start, unsigned long end)
>> +{
>> +	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
>> +		mm->context.vdso_base = 0;
>> +}
>> +
>> +static inline void arch_bprm_mm_init(struct mm_struct *mm,
>> +				     struct vm_area_struct *vma)
>> +{
>> +}
>> +
>> +#define __HAVE_ARCH_REMAP
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +	/*
>> +	 * mremap don't allow moving multiple vma so we can limit the check
>> +	 * to old_start == vdso_base.
> 
> s/mremap don't allow moving multiple vma
>   mremap() doesn't allow moving multiple vmas
> 
> right?

Sure you're right.

I'll provide a v3 fixing that comment.

Thanks,
Laurent.

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

[Laurent Dufour]

On 25/03/2015 13:11, Ingo Molnar wrote:
> 
> * Laurent Dufour <ldufour@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 the vDSO has been
>> moved is not pointing to the new sigreturn address.
>>
>> This patch handles vDSO remapping and unmapping.
>>
>> Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
>> index 73382eba02dc..be5dca3f7826 100644
>> --- a/arch/powerpc/include/asm/mmu_context.h
>> +++ b/arch/powerpc/include/asm/mmu_context.h
>> @@ -8,7 +8,6 @@
>>  #include <linux/spinlock.h>
>>  #include <asm/mmu.h>	
>>  #include <asm/cputable.h>
>> -#include <asm-generic/mm_hooks.h>
>>  #include <asm/cputhreads.h>
>>  
>>  /*
>> @@ -109,5 +108,40 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
>>  #endif
>>  }
>>  
>> +static inline void arch_dup_mmap(struct mm_struct *oldmm,
>> +				 struct mm_struct *mm)
>> +{
>> +}
>> +
>> +static inline void arch_exit_mmap(struct mm_struct *mm)
>> +{
>> +}
>> +
>> +static inline void arch_unmap(struct mm_struct *mm,
>> +			struct vm_area_struct *vma,
>> +			unsigned long start, unsigned long end)
>> +{
>> +	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
>> +		mm->context.vdso_base = 0;
>> +}
>> +
>> +static inline void arch_bprm_mm_init(struct mm_struct *mm,
>> +				     struct vm_area_struct *vma)
>> +{
>> +}
>> +
>> +#define __HAVE_ARCH_REMAP
>> +static inline void arch_remap(struct mm_struct *mm,
>> +			      unsigned long old_start, unsigned long old_end,
>> +			      unsigned long new_start, unsigned long new_end)
>> +{
>> +	/*
>> +	 * mremap don't allow moving multiple vma so we can limit the check
>> +	 * to old_start == vdso_base.
> 
> s/mremap don't allow moving multiple vma
>   mremap() doesn't allow moving multiple vmas
> 
> right?

Sure you're right.

I'll provide a v3 fixing that comment.

Thanks,
Laurent.

--
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>

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

[Laurent Dufour]

CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.

However some architectures like powerpc are keeping a reference to the vDSO
base address to build the signal return stack frame by calling the vDSO
sigreturn service. So once the vDSO has been moved, this reference is no
more valid and the signal frame built later are not usable.

This patch serie is introducing a new mm hook 'arch_remap' which is called
when mremap is done and the mm lock still hold. The next patch is adding the
vDSO remap and unmap tracking to the powerpc architecture.

Changes in v3:
--------------
- Fixed grammatical error in a comment of the second 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 remap

 arch/powerpc/include/asm/mmu_context.h | 36 +++++++++++++++++++++++++++++++++-
 mm/mremap.c                            | 11 +++++++++--
 2 files changed, 44 insertions(+), 3 deletions(-)

-- 
1.9.1

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

[Laurent Dufour]

CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.

However some architectures like powerpc are keeping a reference to the vDSO
base address to build the signal return stack frame by calling the vDSO
sigreturn service. So once the vDSO has been moved, this reference is no
more valid and the signal frame built later are not usable.

This patch serie is introducing a new mm hook 'arch_remap' which is called
when mremap is done and the mm lock still hold. The next patch is adding the
vDSO remap and unmap tracking to the powerpc architecture.

Changes in v3:
--------------
- Fixed grammatical error in a comment of the second 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 remap

 arch/powerpc/include/asm/mmu_context.h | 36 +++++++++++++++++++++++++++++++++-
 mm/mremap.c                            | 11 +++++++++--
 2 files changed, 44 insertions(+), 3 deletions(-)

-- 
1.9.1

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

[Laurent Dufour]

CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.

However some architectures like powerpc are keeping a reference to the vDSO
base address to build the signal return stack frame by calling the vDSO
sigreturn service. So once the vDSO has been moved, this reference is no
more valid and the signal frame built later are not usable.

This patch serie is introducing a new mm hook 'arch_remap' which is called
when mremap is done and the mm lock still hold. The next patch is adding the
vDSO remap and unmap tracking to the powerpc architecture.

Changes in v3:
--------------
- Fixed grammatical error in a comment of the second 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 remap

 arch/powerpc/include/asm/mmu_context.h | 36 +++++++++++++++++++++++++++++++++-
 mm/mremap.c                            | 11 +++++++++--
 2 files changed, 44 insertions(+), 3 deletions(-)

-- 
1.9.1

--
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>

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

[Laurent Dufour]

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>
---
 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 @@
 
 #include <asm/cacheflush.h>
 #include <asm/tlbflush.h>
+#include <asm/mmu_context.h>
 
 #include "internal.h"
 
@@ -286,8 +287,14 @@ 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)
-		vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+	} else {
+		if (vma->vm_file && vma->vm_file->f_op->mremap)
+			vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+#ifdef __HAVE_ARCH_REMAP
+		arch_remap(mm, old_addr, old_addr+old_len,
+			   new_addr, new_addr+new_len);
+#endif
+	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */
 	if (vm_flags & VM_ACCOUNT) {
-- 
1.9.1

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

[Laurent Dufour]

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>
---
 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 @@
 
 #include <asm/cacheflush.h>
 #include <asm/tlbflush.h>
+#include <asm/mmu_context.h>
 
 #include "internal.h"
 
@@ -286,8 +287,14 @@ 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)
-		vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+	} else {
+		if (vma->vm_file && vma->vm_file->f_op->mremap)
+			vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+#ifdef __HAVE_ARCH_REMAP
+		arch_remap(mm, old_addr, old_addr+old_len,
+			   new_addr, new_addr+new_len);
+#endif
+	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */
 	if (vm_flags & VM_ACCOUNT) {
-- 
1.9.1

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

[Laurent Dufour]

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>
---
 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 @@
 
 #include <asm/cacheflush.h>
 #include <asm/tlbflush.h>
+#include <asm/mmu_context.h>
 
 #include "internal.h"
 
@@ -286,8 +287,14 @@ 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)
-		vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+	} else {
+		if (vma->vm_file && vma->vm_file->f_op->mremap)
+			vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+#ifdef __HAVE_ARCH_REMAP
+		arch_remap(mm, old_addr, old_addr+old_len,
+			   new_addr, new_addr+new_len);
+#endif
+	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */
 	if (vm_flags & VM_ACCOUNT) {
-- 
1.9.1

--
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>

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

[Laurent Dufour]

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 the vDSO has been
moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.

Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
index 73382eba02dc..7d315c1898d4 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*
@@ -109,5 +108,40 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
 #endif
 }
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				 struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+static inline void arch_unmap(struct mm_struct *mm,
+			struct vm_area_struct *vma,
+			unsigned long start, unsigned long end)
+{
+	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
+		mm->context.vdso_base = 0;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	/*
+	 * mremap() doesn't allow moving multiple vmas so we can limit the
+	 * check to old_start == vdso_base.
+	 */
+	if (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
-- 
1.9.1

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

[Laurent Dufour]

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 the vDSO has been
moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.

Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
index 73382eba02dc..7d315c1898d4 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*
@@ -109,5 +108,40 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
 #endif
 }
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				 struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+static inline void arch_unmap(struct mm_struct *mm,
+			struct vm_area_struct *vma,
+			unsigned long start, unsigned long end)
+{
+	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
+		mm->context.vdso_base = 0;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	/*
+	 * mremap() doesn't allow moving multiple vmas so we can limit the
+	 * check to old_start == vdso_base.
+	 */
+	if (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
-- 
1.9.1

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

[Laurent Dufour]

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 the vDSO has been
moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.

Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
index 73382eba02dc..7d315c1898d4 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*
@@ -109,5 +108,40 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
 #endif
 }
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				 struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+static inline void arch_unmap(struct mm_struct *mm,
+			struct vm_area_struct *vma,
+			unsigned long start, unsigned long end)
+{
+	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
+		mm->context.vdso_base = 0;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	/*
+	 * mremap() doesn't allow moving multiple vmas so we can limit the
+	 * check to old_start == vdso_base.
+	 */
+	if (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
-- 
1.9.1

--
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>

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

[Ingo Molnar]

* Laurent Dufour <ldufour@linux.vnet.ibm.com> wrote:

> +static inline void arch_unmap(struct mm_struct *mm,
> +			struct vm_area_struct *vma,
> +			unsigned long start, unsigned long end)
> +{
> +	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> +		mm->context.vdso_base = 0;
> +}

So AFAICS PowerPC can have multi-page vDSOs, right?

So what happens if I munmap() the middle or end of the vDSO? The above 
condition only seems to cover unmaps that affect the first page. I 
think 'affects any page' ought to be the right condition? (But I know 
nothing about PowerPC so I might be wrong.)


> +#define __HAVE_ARCH_REMAP
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +	/*
> +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> +	 * check to old_start == vdso_base.
> +	 */
> +	if (old_start == mm->context.vdso_base)
> +		mm->context.vdso_base = new_start;
> +}

mremap() doesn't allow moving multiple vmas, but it allows the 
movement of multi-page vmas and it also allows partial mremap()s, 
where it will split up a vma.

In particular, what happens if an mremap() is done with 
old_start == vdso_base, but a shorter end than the end of the vDSO? 
(i.e. a partial mremap() with fewer pages than the vDSO size)

Thanks,

	Ingo

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

[Ingo Molnar]

* Laurent Dufour <ldufour@linux.vnet.ibm.com> wrote:

> +static inline void arch_unmap(struct mm_struct *mm,
> +			struct vm_area_struct *vma,
> +			unsigned long start, unsigned long end)
> +{
> +	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> +		mm->context.vdso_base = 0;
> +}

So AFAICS PowerPC can have multi-page vDSOs, right?

So what happens if I munmap() the middle or end of the vDSO? The above 
condition only seems to cover unmaps that affect the first page. I 
think 'affects any page' ought to be the right condition? (But I know 
nothing about PowerPC so I might be wrong.)


> +#define __HAVE_ARCH_REMAP
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +	/*
> +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> +	 * check to old_start == vdso_base.
> +	 */
> +	if (old_start == mm->context.vdso_base)
> +		mm->context.vdso_base = new_start;
> +}

mremap() doesn't allow moving multiple vmas, but it allows the 
movement of multi-page vmas and it also allows partial mremap()s, 
where it will split up a vma.

In particular, what happens if an mremap() is done with 
old_start == vdso_base, but a shorter end than the end of the vDSO? 
(i.e. a partial mremap() with fewer pages than the vDSO size)

Thanks,

	Ingo

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

[Ingo Molnar]

* Laurent Dufour <ldufour@linux.vnet.ibm.com> wrote:

> +static inline void arch_unmap(struct mm_struct *mm,
> +			struct vm_area_struct *vma,
> +			unsigned long start, unsigned long end)
> +{
> +	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> +		mm->context.vdso_base = 0;
> +}

So AFAICS PowerPC can have multi-page vDSOs, right?

So what happens if I munmap() the middle or end of the vDSO? The above 
condition only seems to cover unmaps that affect the first page. I 
think 'affects any page' ought to be the right condition? (But I know 
nothing about PowerPC so I might be wrong.)


> +#define __HAVE_ARCH_REMAP
> +static inline void arch_remap(struct mm_struct *mm,
> +			      unsigned long old_start, unsigned long old_end,
> +			      unsigned long new_start, unsigned long new_end)
> +{
> +	/*
> +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> +	 * check to old_start == vdso_base.
> +	 */
> +	if (old_start == mm->context.vdso_base)
> +		mm->context.vdso_base = new_start;
> +}

mremap() doesn't allow moving multiple vmas, but it allows the 
movement of multi-page vmas and it also allows partial mremap()s, 
where it will split up a vma.

In particular, what happens if an mremap() is done with 
old_start == vdso_base, but a shorter end than the end of the vDSO? 
(i.e. a partial mremap() with fewer pages than the vDSO size)

Thanks,

	Ingo

--
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>

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

[Ingo Molnar]

* Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
> > +{
> > +	/*
> > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > +	 * check to old_start == vdso_base.
> > +	 */
> > +	if (old_start == mm->context.vdso_base)
> > +		mm->context.vdso_base = new_start;
> > +}
> 
> mremap() doesn't allow moving multiple vmas, but it allows the 
> movement of multi-page vmas and it also allows partial mremap()s, 
> where it will split up a vma.

I.e. mremap() supports the shrinking (and growing) of vmas. In that 
case mremap() will unmap the end of the vma and will shrink the 
remaining vDSO vma.

Doesn't that result in a non-working vDSO that should zero out 
vdso_base?

Thanks,

	Ingo

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

[Ingo Molnar]

* Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
> > +{
> > +	/*
> > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > +	 * check to old_start == vdso_base.
> > +	 */
> > +	if (old_start == mm->context.vdso_base)
> > +		mm->context.vdso_base = new_start;
> > +}
> 
> mremap() doesn't allow moving multiple vmas, but it allows the 
> movement of multi-page vmas and it also allows partial mremap()s, 
> where it will split up a vma.

I.e. mremap() supports the shrinking (and growing) of vmas. In that 
case mremap() will unmap the end of the vma and will shrink the 
remaining vDSO vma.

Doesn't that result in a non-working vDSO that should zero out 
vdso_base?

Thanks,

	Ingo

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

[Ingo Molnar]

* Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
> > +{
> > +	/*
> > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > +	 * check to old_start == vdso_base.
> > +	 */
> > +	if (old_start == mm->context.vdso_base)
> > +		mm->context.vdso_base = new_start;
> > +}
> 
> mremap() doesn't allow moving multiple vmas, but it allows the 
> movement of multi-page vmas and it also allows partial mremap()s, 
> where it will split up a vma.

I.e. mremap() supports the shrinking (and growing) of vmas. In that 
case mremap() will unmap the end of the vma and will shrink the 
remaining vDSO vma.

Doesn't that result in a non-working vDSO that should zero out 
vdso_base?

Thanks,

	Ingo

--
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>

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

[Benjamin Herrenschmidt]

On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> * Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
> > > +{
> > > +	/*
> > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > +	 * check to old_start == vdso_base.
> > > +	 */
> > > +	if (old_start == mm->context.vdso_base)
> > > +		mm->context.vdso_base = new_start;
> > > +}
> > 
> > mremap() doesn't allow moving multiple vmas, but it allows the 
> > movement of multi-page vmas and it also allows partial mremap()s, 
> > where it will split up a vma.
> 
> I.e. mremap() supports the shrinking (and growing) of vmas. In that 
> case mremap() will unmap the end of the vma and will shrink the 
> remaining vDSO vma.
> 
> Doesn't that result in a non-working vDSO that should zero out 
> vdso_base?

Right. Now we can't completely prevent the user from shooting itself in
the foot I suppose, though there is a legit usage scenario which is to
move the vDSO around which it would be nice to support. I think it's
reasonable to put the onus on the user here to do the right thing.

Cheers,
Ben.

> Thanks,
> 
> 	Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Benjamin Herrenschmidt]

On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> * Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
> > > +{
> > > +	/*
> > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > +	 * check to old_start == vdso_base.
> > > +	 */
> > > +	if (old_start == mm->context.vdso_base)
> > > +		mm->context.vdso_base = new_start;
> > > +}
> > 
> > mremap() doesn't allow moving multiple vmas, but it allows the 
> > movement of multi-page vmas and it also allows partial mremap()s, 
> > where it will split up a vma.
> 
> I.e. mremap() supports the shrinking (and growing) of vmas. In that 
> case mremap() will unmap the end of the vma and will shrink the 
> remaining vDSO vma.
> 
> Doesn't that result in a non-working vDSO that should zero out 
> vdso_base?

Right. Now we can't completely prevent the user from shooting itself in
the foot I suppose, though there is a legit usage scenario which is to
move the vDSO around which it would be nice to support. I think it's
reasonable to put the onus on the user here to do the right thing.

Cheers,
Ben.

> Thanks,
> 
> 	Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Benjamin Herrenschmidt]

On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> * Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
> > > +{
> > > +	/*
> > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > +	 * check to old_start == vdso_base.
> > > +	 */
> > > +	if (old_start == mm->context.vdso_base)
> > > +		mm->context.vdso_base = new_start;
> > > +}
> > 
> > mremap() doesn't allow moving multiple vmas, but it allows the 
> > movement of multi-page vmas and it also allows partial mremap()s, 
> > where it will split up a vma.
> 
> I.e. mremap() supports the shrinking (and growing) of vmas. In that 
> case mremap() will unmap the end of the vma and will shrink the 
> remaining vDSO vma.
> 
> Doesn't that result in a non-working vDSO that should zero out 
> vdso_base?

Right. Now we can't completely prevent the user from shooting itself in
the foot I suppose, though there is a legit usage scenario which is to
move the vDSO around which it would be nice to support. I think it's
reasonable to put the onus on the user here to do the right thing.

Cheers,
Ben.

> Thanks,
> 
> 	Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Benjamin Herrenschmidt]

On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> * Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
> > > +{
> > > +	/*
> > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > +	 * check to old_start == vdso_base.
> > > +	 */
> > > +	if (old_start == mm->context.vdso_base)
> > > +		mm->context.vdso_base = new_start;
> > > +}
> > 
> > mremap() doesn't allow moving multiple vmas, but it allows the 
> > movement of multi-page vmas and it also allows partial mremap()s, 
> > where it will split up a vma.
> 
> I.e. mremap() supports the shrinking (and growing) of vmas. In that 
> case mremap() will unmap the end of the vma and will shrink the 
> remaining vDSO vma.
> 
> Doesn't that result in a non-working vDSO that should zero out 
> vdso_base?

Right. Now we can't completely prevent the user from shooting itself in
the foot I suppose, though there is a legit usage scenario which is to
move the vDSO around which it would be nice to support. I think it's
reasonable to put the onus on the user here to do the right thing.

Cheers,
Ben.

> Thanks,
> 
> 	Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


--
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>

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

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > * Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
> > > > +{
> > > > +	/*
> > > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > > +	 * check to old_start == vdso_base.
> > > > +	 */
> > > > +	if (old_start == mm->context.vdso_base)
> > > > +		mm->context.vdso_base = new_start;
> > > > +}
> > > 
> > > mremap() doesn't allow moving multiple vmas, but it allows the 
> > > movement of multi-page vmas and it also allows partial mremap()s, 
> > > where it will split up a vma.
> > 
> > I.e. mremap() supports the shrinking (and growing) of vmas. In that 
> > case mremap() will unmap the end of the vma and will shrink the 
> > remaining vDSO vma.
> > 
> > Doesn't that result in a non-working vDSO that should zero out 
> > vdso_base?
> 
> Right. Now we can't completely prevent the user from shooting itself 
> in the foot I suppose, though there is a legit usage scenario which 
> is to move the vDSO around which it would be nice to support. I 
> think it's reasonable to put the onus on the user here to do the 
> right thing.

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 the vDSO is OK, or 
don't ...

There's also the question of mprotect(): can users mprotect() the vDSO 
on PowerPC?

Thanks,

	Ingo

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

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > * Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
> > > > +{
> > > > +	/*
> > > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > > +	 * check to old_start == vdso_base.
> > > > +	 */
> > > > +	if (old_start == mm->context.vdso_base)
> > > > +		mm->context.vdso_base = new_start;
> > > > +}
> > > 
> > > mremap() doesn't allow moving multiple vmas, but it allows the 
> > > movement of multi-page vmas and it also allows partial mremap()s, 
> > > where it will split up a vma.
> > 
> > I.e. mremap() supports the shrinking (and growing) of vmas. In that 
> > case mremap() will unmap the end of the vma and will shrink the 
> > remaining vDSO vma.
> > 
> > Doesn't that result in a non-working vDSO that should zero out 
> > vdso_base?
> 
> Right. Now we can't completely prevent the user from shooting itself 
> in the foot I suppose, though there is a legit usage scenario which 
> is to move the vDSO around which it would be nice to support. I 
> think it's reasonable to put the onus on the user here to do the 
> right thing.

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 the vDSO is OK, or 
don't ...

There's also the question of mprotect(): can users mprotect() the vDSO 
on PowerPC?

Thanks,

	Ingo

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

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > * Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
> > > > +{
> > > > +	/*
> > > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > > +	 * check to old_start == vdso_base.
> > > > +	 */
> > > > +	if (old_start == mm->context.vdso_base)
> > > > +		mm->context.vdso_base = new_start;
> > > > +}
> > > 
> > > mremap() doesn't allow moving multiple vmas, but it allows the 
> > > movement of multi-page vmas and it also allows partial mremap()s, 
> > > where it will split up a vma.
> > 
> > I.e. mremap() supports the shrinking (and growing) of vmas. In that 
> > case mremap() will unmap the end of the vma and will shrink the 
> > remaining vDSO vma.
> > 
> > Doesn't that result in a non-working vDSO that should zero out 
> > vdso_base?
> 
> Right. Now we can't completely prevent the user from shooting itself 
> in the foot I suppose, though there is a legit usage scenario which 
> is to move the vDSO around which it would be nice to support. I 
> think it's reasonable to put the onus on the user here to do the 
> right thing.

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 the vDSO is OK, or 
don't ...

There's also the question of mprotect(): can users mprotect() the vDSO 
on PowerPC?

Thanks,

	Ingo

--
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>

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

[Laurent Dufour]

On 26/03/2015 10:43, Ingo Molnar wrote:
> 
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
>> On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
>>> * Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
>>>>> +{
>>>>> +	/*
>>>>> +	 * mremap() doesn't allow moving multiple vmas so we can limit the
>>>>> +	 * check to old_start == vdso_base.
>>>>> +	 */
>>>>> +	if (old_start == mm->context.vdso_base)
>>>>> +		mm->context.vdso_base = new_start;
>>>>> +}
>>>>
>>>> mremap() doesn't allow moving multiple vmas, but it allows the 
>>>> movement of multi-page vmas and it also allows partial mremap()s, 
>>>> where it will split up a vma.
>>>
>>> I.e. mremap() supports the shrinking (and growing) of vmas. In that 
>>> case mremap() will unmap the end of the vma and will shrink the 
>>> remaining vDSO vma.
>>>
>>> Doesn't that result in a non-working vDSO that should zero out 
>>> vdso_base?
>>
>> Right. Now we can't completely prevent the user from shooting itself 
>> in the foot I suppose, though there is a legit usage scenario which 
>> is to move the vDSO around which it would be nice to support. I 
>> think it's reasonable to put the onus on the user here to do the 
>> right thing.
> 
> 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 the vDSO is OK, or 
> don't ...

That's a good option, but it may be hard to achieve in the case the vDSO
area has been splitted in multiple pieces.

Not sure there is a right way to handle that, here this is a best
effort, allowing a process to unmap its vDSO and having the sigreturn
call done through the stack area (it has to make it executable).

Anyway I'll dig into that, assuming that the vdso_base pointer should be
clear if a part of the vDSO is moved or unmapped. The patch will be
larger since I'll have to get the vDSO size which is private to the
vdso.c file.

> There's also the question of mprotect(): can users mprotect() the vDSO 
> on PowerPC?

Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and
certainly all the other architectures.
Furthermore, if it is done on a partial part of the vDSO it is splitting
the vma...

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

[Laurent Dufour]

On 26/03/2015 10:43, Ingo Molnar wrote:
> 
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
>> On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
>>> * Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
>>>>> +{
>>>>> +	/*
>>>>> +	 * mremap() doesn't allow moving multiple vmas so we can limit the
>>>>> +	 * check to old_start == vdso_base.
>>>>> +	 */
>>>>> +	if (old_start == mm->context.vdso_base)
>>>>> +		mm->context.vdso_base = new_start;
>>>>> +}
>>>>
>>>> mremap() doesn't allow moving multiple vmas, but it allows the 
>>>> movement of multi-page vmas and it also allows partial mremap()s, 
>>>> where it will split up a vma.
>>>
>>> I.e. mremap() supports the shrinking (and growing) of vmas. In that 
>>> case mremap() will unmap the end of the vma and will shrink the 
>>> remaining vDSO vma.
>>>
>>> Doesn't that result in a non-working vDSO that should zero out 
>>> vdso_base?
>>
>> Right. Now we can't completely prevent the user from shooting itself 
>> in the foot I suppose, though there is a legit usage scenario which 
>> is to move the vDSO around which it would be nice to support. I 
>> think it's reasonable to put the onus on the user here to do the 
>> right thing.
> 
> 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 the vDSO is OK, or 
> don't ...

That's a good option, but it may be hard to achieve in the case the vDSO
area has been splitted in multiple pieces.

Not sure there is a right way to handle that, here this is a best
effort, allowing a process to unmap its vDSO and having the sigreturn
call done through the stack area (it has to make it executable).

Anyway I'll dig into that, assuming that the vdso_base pointer should be
clear if a part of the vDSO is moved or unmapped. The patch will be
larger since I'll have to get the vDSO size which is private to the
vdso.c file.

> There's also the question of mprotect(): can users mprotect() the vDSO 
> on PowerPC?

Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and
certainly all the other architectures.
Furthermore, if it is done on a partial part of the vDSO it is splitting
the vma...

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

[Laurent Dufour]

On 26/03/2015 10:43, Ingo Molnar wrote:
> 
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
>> On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
>>> * Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
>>>>> +{
>>>>> +	/*
>>>>> +	 * mremap() doesn't allow moving multiple vmas so we can limit the
>>>>> +	 * check to old_start == vdso_base.
>>>>> +	 */
>>>>> +	if (old_start == mm->context.vdso_base)
>>>>> +		mm->context.vdso_base = new_start;
>>>>> +}
>>>>
>>>> mremap() doesn't allow moving multiple vmas, but it allows the 
>>>> movement of multi-page vmas and it also allows partial mremap()s, 
>>>> where it will split up a vma.
>>>
>>> I.e. mremap() supports the shrinking (and growing) of vmas. In that 
>>> case mremap() will unmap the end of the vma and will shrink the 
>>> remaining vDSO vma.
>>>
>>> Doesn't that result in a non-working vDSO that should zero out 
>>> vdso_base?
>>
>> Right. Now we can't completely prevent the user from shooting itself 
>> in the foot I suppose, though there is a legit usage scenario which 
>> is to move the vDSO around which it would be nice to support. I 
>> think it's reasonable to put the onus on the user here to do the 
>> right thing.
> 
> 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 the vDSO is OK, or 
> don't ...

That's a good option, but it may be hard to achieve in the case the vDSO
area has been splitted in multiple pieces.

Not sure there is a right way to handle that, here this is a best
effort, allowing a process to unmap its vDSO and having the sigreturn
call done through the stack area (it has to make it executable).

Anyway I'll dig into that, assuming that the vdso_base pointer should be
clear if a part of the vDSO is moved or unmapped. The patch will be
larger since I'll have to get the vDSO size which is private to the
vdso.c file.

> There's also the question of mprotect(): can users mprotect() the vDSO 
> on PowerPC?

Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and
certainly all the other architectures.
Furthermore, if it is done on a partial part of the vDSO it is splitting
the vma...



--
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>

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

[Ingo Molnar]

* Laurent Dufour <ldufour@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 
> > the vDSO is OK, or don't ...
> 
> That's a good option, but it may be hard to achieve in the case the 
> vDSO area has been splitted in multiple pieces.
>
> Not sure there is a right way to handle that, here this is a best 
> effort, allowing a process to unmap its vDSO and having the 
> sigreturn call done through the stack area (it has to make it 
> executable).
> 
> Anyway I'll dig into that, assuming that the vdso_base pointer 
> should be clear if a part of the vDSO is moved or unmapped. The 
> patch will be larger since I'll have to get the vDSO size which is 
> private to the vdso.c file.

At least for munmap() I don't think that's a worry: once unmapped 
(even if just partially), vdso_base becomes zero and won't ever be set 
again.

So no need to track the zillion pieces, should there be any: Humpty 
Dumpty won't be whole again, right?

> > There's also the question of mprotect(): can users mprotect() the 
> > vDSO on PowerPC?
> 
> Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and 
> certainly all the other architectures. Furthermore, if it is done on 
> a partial part of the vDSO it is splitting the vma...

btw., CRIU's main purpose here is to reconstruct a vDSO that was 
originally randomized, but whose address must now be reproduced as-is, 
right?

In that sense detecting the 'good' mremap() as your patch does should 
do the trick and is certainly not objectionable IMHO - I was just 
wondering whether we could make a perfect job very simply.

Thanks,

	Ingo

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

[Ingo Molnar]

* Laurent Dufour <ldufour@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 
> > the vDSO is OK, or don't ...
> 
> That's a good option, but it may be hard to achieve in the case the 
> vDSO area has been splitted in multiple pieces.
>
> Not sure there is a right way to handle that, here this is a best 
> effort, allowing a process to unmap its vDSO and having the 
> sigreturn call done through the stack area (it has to make it 
> executable).
> 
> Anyway I'll dig into that, assuming that the vdso_base pointer 
> should be clear if a part of the vDSO is moved or unmapped. The 
> patch will be larger since I'll have to get the vDSO size which is 
> private to the vdso.c file.

At least for munmap() I don't think that's a worry: once unmapped 
(even if just partially), vdso_base becomes zero and won't ever be set 
again.

So no need to track the zillion pieces, should there be any: Humpty 
Dumpty won't be whole again, right?

> > There's also the question of mprotect(): can users mprotect() the 
> > vDSO on PowerPC?
> 
> Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and 
> certainly all the other architectures. Furthermore, if it is done on 
> a partial part of the vDSO it is splitting the vma...

btw., CRIU's main purpose here is to reconstruct a vDSO that was 
originally randomized, but whose address must now be reproduced as-is, 
right?

In that sense detecting the 'good' mremap() as your patch does should 
do the trick and is certainly not objectionable IMHO - I was just 
wondering whether we could make a perfect job very simply.

Thanks,

	Ingo

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

[Ingo Molnar]

* Laurent Dufour <ldufour@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 
> > the vDSO is OK, or don't ...
> 
> That's a good option, but it may be hard to achieve in the case the 
> vDSO area has been splitted in multiple pieces.
>
> Not sure there is a right way to handle that, here this is a best 
> effort, allowing a process to unmap its vDSO and having the 
> sigreturn call done through the stack area (it has to make it 
> executable).
> 
> Anyway I'll dig into that, assuming that the vdso_base pointer 
> should be clear if a part of the vDSO is moved or unmapped. The 
> patch will be larger since I'll have to get the vDSO size which is 
> private to the vdso.c file.

At least for munmap() I don't think that's a worry: once unmapped 
(even if just partially), vdso_base becomes zero and won't ever be set 
again.

So no need to track the zillion pieces, should there be any: Humpty 
Dumpty won't be whole again, right?

> > There's also the question of mprotect(): can users mprotect() the 
> > vDSO on PowerPC?
> 
> Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and 
> certainly all the other architectures. Furthermore, if it is done on 
> a partial part of the vDSO it is splitting the vma...

btw., CRIU's main purpose here is to reconstruct a vDSO that was 
originally randomized, but whose address must now be reproduced as-is, 
right?

In that sense detecting the 'good' mremap() as your patch does should 
do the trick and is certainly not objectionable IMHO - I was just 
wondering whether we could make a perfect job very simply.

Thanks,

	Ingo

--
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>

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

[Laurent Dufour]

On 26/03/2015 15:17, Ingo Molnar wrote:
> 
> * Laurent Dufour <ldufour@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 
>>> the vDSO is OK, or don't ...
>>
>> That's a good option, but it may be hard to achieve in the case the 
>> vDSO area has been splitted in multiple pieces.
>>
>> Not sure there is a right way to handle that, here this is a best 
>> effort, allowing a process to unmap its vDSO and having the 
>> sigreturn call done through the stack area (it has to make it 
>> executable).
>>
>> Anyway I'll dig into that, assuming that the vdso_base pointer 
>> should be clear if a part of the vDSO is moved or unmapped. The 
>> patch will be larger since I'll have to get the vDSO size which is 
>> private to the vdso.c file.
> 
> At least for munmap() I don't think that's a worry: once unmapped 
> (even if just partially), vdso_base becomes zero and won't ever be set 
> again.
> 
> So no need to track the zillion pieces, should there be any: Humpty 
> Dumpty won't be whole again, right?

My idea is to clear vdso_base if at least part of the vdso is unmap.
But since some part of the vdso may have been moved and unmapped later,
to be complete, the patch has to handle partial mremap() of the vDSO
too. Otherwise such a scenario will not be detected:

	new_area = mremap(vdso_base + page_size, ....);
	munmap(new_area,...);

>>> There's also the question of mprotect(): can users mprotect() the 
>>> vDSO on PowerPC?
>>
>> Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and 
>> certainly all the other architectures. Furthermore, if it is done on 
>> a partial part of the vDSO it is splitting the vma...
> 
> btw., CRIU's main purpose here is to reconstruct a vDSO that was 
> originally randomized, but whose address must now be reproduced as-is, 
> right?

You're right, CRIU has to move the vDSO to the same address it has at
checkpoint time.

> In that sense detecting the 'good' mremap() as your patch does should 
> do the trick and is certainly not objectionable IMHO - I was just 
> wondering whether we could make a perfect job very simply.

I'd try to address the perfect job, this may complexify the patch,
especially because the vdso's size is not recorded in the PowerPC
mm_context structure. Not sure it is a good idea to extend that structure..

Thanks,
Laurent.

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

[Laurent Dufour]

On 26/03/2015 15:17, Ingo Molnar wrote:
> 
> * Laurent Dufour <ldufour@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 
>>> the vDSO is OK, or don't ...
>>
>> That's a good option, but it may be hard to achieve in the case the 
>> vDSO area has been splitted in multiple pieces.
>>
>> Not sure there is a right way to handle that, here this is a best 
>> effort, allowing a process to unmap its vDSO and having the 
>> sigreturn call done through the stack area (it has to make it 
>> executable).
>>
>> Anyway I'll dig into that, assuming that the vdso_base pointer 
>> should be clear if a part of the vDSO is moved or unmapped. The 
>> patch will be larger since I'll have to get the vDSO size which is 
>> private to the vdso.c file.
> 
> At least for munmap() I don't think that's a worry: once unmapped 
> (even if just partially), vdso_base becomes zero and won't ever be set 
> again.
> 
> So no need to track the zillion pieces, should there be any: Humpty 
> Dumpty won't be whole again, right?

My idea is to clear vdso_base if at least part of the vdso is unmap.
But since some part of the vdso may have been moved and unmapped later,
to be complete, the patch has to handle partial mremap() of the vDSO
too. Otherwise such a scenario will not be detected:

	new_area = mremap(vdso_base + page_size, ....);
	munmap(new_area,...);

>>> There's also the question of mprotect(): can users mprotect() the 
>>> vDSO on PowerPC?
>>
>> Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and 
>> certainly all the other architectures. Furthermore, if it is done on 
>> a partial part of the vDSO it is splitting the vma...
> 
> btw., CRIU's main purpose here is to reconstruct a vDSO that was 
> originally randomized, but whose address must now be reproduced as-is, 
> right?

You're right, CRIU has to move the vDSO to the same address it has at
checkpoint time.

> In that sense detecting the 'good' mremap() as your patch does should 
> do the trick and is certainly not objectionable IMHO - I was just 
> wondering whether we could make a perfect job very simply.

I'd try to address the perfect job, this may complexify the patch,
especially because the vdso's size is not recorded in the PowerPC
mm_context structure. Not sure it is a good idea to extend that structure..

Thanks,
Laurent.

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

[Laurent Dufour]

On 26/03/2015 15:17, Ingo Molnar wrote:
> 
> * Laurent Dufour <ldufour@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 
>>> the vDSO is OK, or don't ...
>>
>> That's a good option, but it may be hard to achieve in the case the 
>> vDSO area has been splitted in multiple pieces.
>>
>> Not sure there is a right way to handle that, here this is a best 
>> effort, allowing a process to unmap its vDSO and having the 
>> sigreturn call done through the stack area (it has to make it 
>> executable).
>>
>> Anyway I'll dig into that, assuming that the vdso_base pointer 
>> should be clear if a part of the vDSO is moved or unmapped. The 
>> patch will be larger since I'll have to get the vDSO size which is 
>> private to the vdso.c file.
> 
> At least for munmap() I don't think that's a worry: once unmapped 
> (even if just partially), vdso_base becomes zero and won't ever be set 
> again.
> 
> So no need to track the zillion pieces, should there be any: Humpty 
> Dumpty won't be whole again, right?

My idea is to clear vdso_base if at least part of the vdso is unmap.
But since some part of the vdso may have been moved and unmapped later,
to be complete, the patch has to handle partial mremap() of the vDSO
too. Otherwise such a scenario will not be detected:

	new_area = mremap(vdso_base + page_size, ....);
	munmap(new_area,...);

>>> There's also the question of mprotect(): can users mprotect() the 
>>> vDSO on PowerPC?
>>
>> Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and 
>> certainly all the other architectures. Furthermore, if it is done on 
>> a partial part of the vDSO it is splitting the vma...
> 
> btw., CRIU's main purpose here is to reconstruct a vDSO that was 
> originally randomized, but whose address must now be reproduced as-is, 
> right?

You're right, CRIU has to move the vDSO to the same address it has at
checkpoint time.

> In that sense detecting the 'good' mremap() as your patch does should 
> do the trick and is certainly not objectionable IMHO - I was just 
> wondering whether we could make a perfect job very simply.

I'd try to address the perfect job, this may complexify the patch,
especially because the vdso's size is not recorded in the PowerPC
mm_context structure. Not sure it is a good idea to extend that structure..

Thanks,
Laurent.

--
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>

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

[Laurent Dufour]

CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.

However some architectures like powerpc are keeping a reference to the vDSO
base address to build the signal return stack frame by calling the vDSO
sigreturn service. So once the vDSO has been moved, this reference is no
more valid and the signal frame built later are not usable.

This patch serie is introducing a new mm hook 'arch_remap' which is called
when mremap is done and the mm lock still hold. The next patch is adding the
vDSO remap and unmap tracking to the powerpc architecture.

Changes in v4:
--------------
- Reviewing the PowerPC part of the patch to handle partial unmap and remap
  of the vDSO.

Changes in v3:
--------------
- Fixed grammatical error in a comment of the second 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 remap

 arch/powerpc/include/asm/mmu_context.h | 32 +++++++++++++++++++++++++++-
 arch/powerpc/kernel/vdso.c             | 39 ++++++++++++++++++++++++++++++++++
 mm/mremap.c                            | 11 ++++++++--
 3 files changed, 79 insertions(+), 3 deletions(-)

-- 
1.9.1

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

[Laurent Dufour]

CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.

However some architectures like powerpc are keeping a reference to the vDSO
base address to build the signal return stack frame by calling the vDSO
sigreturn service. So once the vDSO has been moved, this reference is no
more valid and the signal frame built later are not usable.

This patch serie is introducing a new mm hook 'arch_remap' which is called
when mremap is done and the mm lock still hold. The next patch is adding the
vDSO remap and unmap tracking to the powerpc architecture.

Changes in v4:
--------------
- Reviewing the PowerPC part of the patch to handle partial unmap and remap
  of the vDSO.

Changes in v3:
--------------
- Fixed grammatical error in a comment of the second 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 remap

 arch/powerpc/include/asm/mmu_context.h | 32 +++++++++++++++++++++++++++-
 arch/powerpc/kernel/vdso.c             | 39 ++++++++++++++++++++++++++++++++++
 mm/mremap.c                            | 11 ++++++++--
 3 files changed, 79 insertions(+), 3 deletions(-)

-- 
1.9.1

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

[Laurent Dufour]

CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.

However some architectures like powerpc are keeping a reference to the vDSO
base address to build the signal return stack frame by calling the vDSO
sigreturn service. So once the vDSO has been moved, this reference is no
more valid and the signal frame built later are not usable.

This patch serie is introducing a new mm hook 'arch_remap' which is called
when mremap is done and the mm lock still hold. The next patch is adding the
vDSO remap and unmap tracking to the powerpc architecture.

Changes in v4:
--------------
- Reviewing the PowerPC part of the patch to handle partial unmap and remap
  of the vDSO.

Changes in v3:
--------------
- Fixed grammatical error in a comment of the second 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 remap

 arch/powerpc/include/asm/mmu_context.h | 32 +++++++++++++++++++++++++++-
 arch/powerpc/kernel/vdso.c             | 39 ++++++++++++++++++++++++++++++++++
 mm/mremap.c                            | 11 ++++++++--
 3 files changed, 79 insertions(+), 3 deletions(-)

-- 
1.9.1

--
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>

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

[Laurent Dufour]

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>
---
 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 @@
 
 #include <asm/cacheflush.h>
 #include <asm/tlbflush.h>
+#include <asm/mmu_context.h>
 
 #include "internal.h"
 
@@ -286,8 +287,14 @@ 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)
-		vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+	} else {
+		if (vma->vm_file && vma->vm_file->f_op->mremap)
+			vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+#ifdef __HAVE_ARCH_REMAP
+		arch_remap(mm, old_addr, old_addr+old_len,
+			   new_addr, new_addr+new_len);
+#endif
+	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */
 	if (vm_flags & VM_ACCOUNT) {
-- 
1.9.1

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

[Laurent Dufour]

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>
---
 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 @@
 
 #include <asm/cacheflush.h>
 #include <asm/tlbflush.h>
+#include <asm/mmu_context.h>
 
 #include "internal.h"
 
@@ -286,8 +287,14 @@ 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)
-		vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+	} else {
+		if (vma->vm_file && vma->vm_file->f_op->mremap)
+			vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+#ifdef __HAVE_ARCH_REMAP
+		arch_remap(mm, old_addr, old_addr+old_len,
+			   new_addr, new_addr+new_len);
+#endif
+	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */
 	if (vm_flags & VM_ACCOUNT) {
-- 
1.9.1

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

[Laurent Dufour]

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>
---
 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 @@
 
 #include <asm/cacheflush.h>
 #include <asm/tlbflush.h>
+#include <asm/mmu_context.h>
 
 #include "internal.h"
 
@@ -286,8 +287,14 @@ 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)
-		vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+	} else {
+		if (vma->vm_file && vma->vm_file->f_op->mremap)
+			vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+#ifdef __HAVE_ARCH_REMAP
+		arch_remap(mm, old_addr, old_addr+old_len,
+			   new_addr, new_addr+new_len);
+#endif
+	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */
 	if (vm_flags & VM_ACCOUNT) {
-- 
1.9.1

--
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>

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

[Laurent Dufour]

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 the vDSO has been
moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.
Moving or unmapping partially the vDSO lead to invalidate it from the
kernel point of view.

Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/mmu_context.h | 32 +++++++++++++++++++++++++++-
 arch/powerpc/kernel/vdso.c             | 39 ++++++++++++++++++++++++++++++++++
 2 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
index 73382eba02dc..67734ce8be67 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*
@@ -109,5 +108,36 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
 #endif
 }
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				 struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+extern void arch_vdso_remap(struct mm_struct *mm,
+			    unsigned long old_start, unsigned long old_end,
+			    unsigned long new_start, unsigned long new_end);
+static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
+			      unsigned long start, unsigned long end)
+{
+	arch_vdso_remap(mm, start, end, 0, 0);
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	arch_vdso_remap(mm, old_start, old_end, new_start, new_end);
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 305eb0d9b768..a11b5d8f36d6 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -283,6 +283,45 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	return rc;
 }
 
+void arch_vdso_remap(struct mm_struct *mm,
+		     unsigned long old_start, unsigned long old_end,
+		     unsigned long new_start, unsigned long new_end)
+{
+	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() implies that we are dealing with the
+	 * current process memory. If there is a call path where mm is not
+	 * owned by the current task, then we'll have need to store the
+	 * vDSO size in the mm->context.
+	 */
+	BUG_ON(current->mm != mm);
+	if (is_32bit_task())
+		vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
+	else
+		vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
+#else
+	vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
+#endif
+	vdso_end += (1<<PAGE_SHIFT); /* data page */
+
+	/* Check if the vDSO is in the range of the remapped area */
+	if ((vdso_start <= old_start && old_start < vdso_end) ||
+	    (vdso_start < old_end && old_end <= vdso_end)  ||
+	    (old_start <= vdso_start && vdso_start < old_end)) {
+		/* Update vdso_base if the vDSO is entirely moved. */
+		if (old_start == vdso_start && old_end == vdso_end &&
+		    (old_end - old_start) == (new_end - new_start))
+			mm->context.vdso_base = new_start;
+		else
+			mm->context.vdso_base = 0;
+	}
+}
+
 const char *arch_vma_name(struct vm_area_struct *vma)
 {
 	if (vma->vm_mm && vma->vm_start == vma->vm_mm->context.vdso_base)
-- 
1.9.1

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

[Laurent Dufour]

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 the vDSO has been
moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.
Moving or unmapping partially the vDSO lead to invalidate it from the
kernel point of view.

Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/mmu_context.h | 32 +++++++++++++++++++++++++++-
 arch/powerpc/kernel/vdso.c             | 39 ++++++++++++++++++++++++++++++++++
 2 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
index 73382eba02dc..67734ce8be67 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*
@@ -109,5 +108,36 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
 #endif
 }
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				 struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+extern void arch_vdso_remap(struct mm_struct *mm,
+			    unsigned long old_start, unsigned long old_end,
+			    unsigned long new_start, unsigned long new_end);
+static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
+			      unsigned long start, unsigned long end)
+{
+	arch_vdso_remap(mm, start, end, 0, 0);
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	arch_vdso_remap(mm, old_start, old_end, new_start, new_end);
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 305eb0d9b768..a11b5d8f36d6 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -283,6 +283,45 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	return rc;
 }
 
+void arch_vdso_remap(struct mm_struct *mm,
+		     unsigned long old_start, unsigned long old_end,
+		     unsigned long new_start, unsigned long new_end)
+{
+	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() implies that we are dealing with the
+	 * current process memory. If there is a call path where mm is not
+	 * owned by the current task, then we'll have need to store the
+	 * vDSO size in the mm->context.
+	 */
+	BUG_ON(current->mm != mm);
+	if (is_32bit_task())
+		vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
+	else
+		vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
+#else
+	vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
+#endif
+	vdso_end += (1<<PAGE_SHIFT); /* data page */
+
+	/* Check if the vDSO is in the range of the remapped area */
+	if ((vdso_start <= old_start && old_start < vdso_end) ||
+	    (vdso_start < old_end && old_end <= vdso_end)  ||
+	    (old_start <= vdso_start && vdso_start < old_end)) {
+		/* Update vdso_base if the vDSO is entirely moved. */
+		if (old_start == vdso_start && old_end == vdso_end &&
+		    (old_end - old_start) == (new_end - new_start))
+			mm->context.vdso_base = new_start;
+		else
+			mm->context.vdso_base = 0;
+	}
+}
+
 const char *arch_vma_name(struct vm_area_struct *vma)
 {
 	if (vma->vm_mm && vma->vm_start == vma->vm_mm->context.vdso_base)
-- 
1.9.1

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

[Laurent Dufour]

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 the vDSO has been
moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.
Moving or unmapping partially the vDSO lead to invalidate it from the
kernel point of view.

Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/mmu_context.h | 32 +++++++++++++++++++++++++++-
 arch/powerpc/kernel/vdso.c             | 39 ++++++++++++++++++++++++++++++++++
 2 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
index 73382eba02dc..67734ce8be67 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*
@@ -109,5 +108,36 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
 #endif
 }
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				 struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+extern void arch_vdso_remap(struct mm_struct *mm,
+			    unsigned long old_start, unsigned long old_end,
+			    unsigned long new_start, unsigned long new_end);
+static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
+			      unsigned long start, unsigned long end)
+{
+	arch_vdso_remap(mm, start, end, 0, 0);
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	arch_vdso_remap(mm, old_start, old_end, new_start, new_end);
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 305eb0d9b768..a11b5d8f36d6 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -283,6 +283,45 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	return rc;
 }
 
+void arch_vdso_remap(struct mm_struct *mm,
+		     unsigned long old_start, unsigned long old_end,
+		     unsigned long new_start, unsigned long new_end)
+{
+	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() implies that we are dealing with the
+	 * current process memory. If there is a call path where mm is not
+	 * owned by the current task, then we'll have need to store the
+	 * vDSO size in the mm->context.
+	 */
+	BUG_ON(current->mm != mm);
+	if (is_32bit_task())
+		vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
+	else
+		vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
+#else
+	vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
+#endif
+	vdso_end += (1<<PAGE_SHIFT); /* data page */
+
+	/* Check if the vDSO is in the range of the remapped area */
+	if ((vdso_start <= old_start && old_start < vdso_end) ||
+	    (vdso_start < old_end && old_end <= vdso_end)  ||
+	    (old_start <= vdso_start && vdso_start < old_end)) {
+		/* Update vdso_base if the vDSO is entirely moved. */
+		if (old_start == vdso_start && old_end == vdso_end &&
+		    (old_end - old_start) == (new_end - new_start))
+			mm->context.vdso_base = new_start;
+		else
+			mm->context.vdso_base = 0;
+	}
+}
+
 const char *arch_vma_name(struct vm_area_struct *vma)
 {
 	if (vma->vm_mm && vma->vm_start == vma->vm_mm->context.vdso_base)
-- 
1.9.1

--
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>

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

[Ingo Molnar]

* Laurent Dufour <ldufour@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() implies that we are dealing with the
> +	 * current process memory. If there is a call path where mm is not
> +	 * owned by the current task, then we'll have need to store the
> +	 * vDSO size in the mm->context.
> +	 */
> +	BUG_ON(current->mm != mm);
> +	if (is_32bit_task())
> +		vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
> +	else
> +		vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
> +#else
> +	vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
> +#endif
> +	vdso_end += (1<<PAGE_SHIFT); /* data page */
> +
> +	/* Check if the vDSO is in the range of the remapped area */
> +	if ((vdso_start <= old_start && old_start < vdso_end) ||
> +	    (vdso_start < old_end && old_end <= vdso_end)  ||
> +	    (old_start <= vdso_start && vdso_start < old_end)) {
> +		/* Update vdso_base if the vDSO is entirely moved. */
> +		if (old_start == vdso_start && old_end == vdso_end &&
> +		    (old_end - old_start) == (new_end - new_start))
> +			mm->context.vdso_base = new_start;
> +		else
> +			mm->context.vdso_base = 0;
> +	}
> +}

Oh my, that really looks awfully complex, as you predicted, and right 
in every mremap() call.

I'm fine with your original, imperfect, KISS approach. Sorry about 
this detour ...

Reviewed-by: Ingo Molnar <mingo@kernel.org>

Thanks,

	Ingo

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

[Ingo Molnar]

* Laurent Dufour <ldufour@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() implies that we are dealing with the
> +	 * current process memory. If there is a call path where mm is not
> +	 * owned by the current task, then we'll have need to store the
> +	 * vDSO size in the mm->context.
> +	 */
> +	BUG_ON(current->mm != mm);
> +	if (is_32bit_task())
> +		vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
> +	else
> +		vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
> +#else
> +	vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
> +#endif
> +	vdso_end += (1<<PAGE_SHIFT); /* data page */
> +
> +	/* Check if the vDSO is in the range of the remapped area */
> +	if ((vdso_start <= old_start && old_start < vdso_end) ||
> +	    (vdso_start < old_end && old_end <= vdso_end)  ||
> +	    (old_start <= vdso_start && vdso_start < old_end)) {
> +		/* Update vdso_base if the vDSO is entirely moved. */
> +		if (old_start == vdso_start && old_end == vdso_end &&
> +		    (old_end - old_start) == (new_end - new_start))
> +			mm->context.vdso_base = new_start;
> +		else
> +			mm->context.vdso_base = 0;
> +	}
> +}

Oh my, that really looks awfully complex, as you predicted, and right 
in every mremap() call.

I'm fine with your original, imperfect, KISS approach. Sorry about 
this detour ...

Reviewed-by: Ingo Molnar <mingo@kernel.org>

Thanks,

	Ingo

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

[Ingo Molnar]

* Laurent Dufour <ldufour@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() implies that we are dealing with the
> +	 * current process memory. If there is a call path where mm is not
> +	 * owned by the current task, then we'll have need to store the
> +	 * vDSO size in the mm->context.
> +	 */
> +	BUG_ON(current->mm != mm);
> +	if (is_32bit_task())
> +		vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
> +	else
> +		vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
> +#else
> +	vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
> +#endif
> +	vdso_end += (1<<PAGE_SHIFT); /* data page */
> +
> +	/* Check if the vDSO is in the range of the remapped area */
> +	if ((vdso_start <= old_start && old_start < vdso_end) ||
> +	    (vdso_start < old_end && old_end <= vdso_end)  ||
> +	    (old_start <= vdso_start && vdso_start < old_end)) {
> +		/* Update vdso_base if the vDSO is entirely moved. */
> +		if (old_start == vdso_start && old_end == vdso_end &&
> +		    (old_end - old_start) == (new_end - new_start))
> +			mm->context.vdso_base = new_start;
> +		else
> +			mm->context.vdso_base = 0;
> +	}
> +}

Oh my, that really looks awfully complex, as you predicted, and right 
in every mremap() call.

I'm fine with your original, imperfect, KISS approach. Sorry about 
this detour ...

Reviewed-by: Ingo Molnar <mingo@kernel.org>

Thanks,

	Ingo

--
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>

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

[Laurent Dufour]

On 26/03/2015 19:55, Ingo Molnar wrote:
> 
> * Laurent Dufour <ldufour@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() implies that we are dealing with the
>> +	 * current process memory. If there is a call path where mm is not
>> +	 * owned by the current task, then we'll have need to store the
>> +	 * vDSO size in the mm->context.
>> +	 */
>> +	BUG_ON(current->mm != mm);
>> +	if (is_32bit_task())
>> +		vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
>> +	else
>> +		vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
>> +#else
>> +	vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
>> +#endif
>> +	vdso_end += (1<<PAGE_SHIFT); /* data page */
>> +
>> +	/* Check if the vDSO is in the range of the remapped area */
>> +	if ((vdso_start <= old_start && old_start < vdso_end) ||
>> +	    (vdso_start < old_end && old_end <= vdso_end)  ||
>> +	    (old_start <= vdso_start && vdso_start < old_end)) {
>> +		/* Update vdso_base if the vDSO is entirely moved. */
>> +		if (old_start == vdso_start && old_end == vdso_end &&
>> +		    (old_end - old_start) == (new_end - new_start))
>> +			mm->context.vdso_base = new_start;
>> +		else
>> +			mm->context.vdso_base = 0;
>> +	}
>> +}
> 
> Oh my, that really looks awfully complex, as you predicted, and right 
> in every mremap() call.

I do agree, that's awfully complex ;)

> I'm fine with your original, imperfect, KISS approach. Sorry about 
> this detour ...
>
> Reviewed-by: Ingo Molnar <mingo@kernel.org>

No problem, so let's stay on the v3 version of the patch.
Thanks for Reviewed-by statement which, I guess, applied to the v3 too.
Should I resend the v3 ?

Thanks,
Laurent.

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

[Laurent Dufour]

On 26/03/2015 19:55, Ingo Molnar wrote:
> 
> * Laurent Dufour <ldufour@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() implies that we are dealing with the
>> +	 * current process memory. If there is a call path where mm is not
>> +	 * owned by the current task, then we'll have need to store the
>> +	 * vDSO size in the mm->context.
>> +	 */
>> +	BUG_ON(current->mm != mm);
>> +	if (is_32bit_task())
>> +		vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
>> +	else
>> +		vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
>> +#else
>> +	vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
>> +#endif
>> +	vdso_end += (1<<PAGE_SHIFT); /* data page */
>> +
>> +	/* Check if the vDSO is in the range of the remapped area */
>> +	if ((vdso_start <= old_start && old_start < vdso_end) ||
>> +	    (vdso_start < old_end && old_end <= vdso_end)  ||
>> +	    (old_start <= vdso_start && vdso_start < old_end)) {
>> +		/* Update vdso_base if the vDSO is entirely moved. */
>> +		if (old_start == vdso_start && old_end == vdso_end &&
>> +		    (old_end - old_start) == (new_end - new_start))
>> +			mm->context.vdso_base = new_start;
>> +		else
>> +			mm->context.vdso_base = 0;
>> +	}
>> +}
> 
> Oh my, that really looks awfully complex, as you predicted, and right 
> in every mremap() call.

I do agree, that's awfully complex ;)

> I'm fine with your original, imperfect, KISS approach. Sorry about 
> this detour ...
>
> Reviewed-by: Ingo Molnar <mingo@kernel.org>

No problem, so let's stay on the v3 version of the patch.
Thanks for Reviewed-by statement which, I guess, applied to the v3 too.
Should I resend the v3 ?

Thanks,
Laurent.

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

[Laurent Dufour]

On 26/03/2015 19:55, Ingo Molnar wrote:
> 
> * Laurent Dufour <ldufour@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() implies that we are dealing with the
>> +	 * current process memory. If there is a call path where mm is not
>> +	 * owned by the current task, then we'll have need to store the
>> +	 * vDSO size in the mm->context.
>> +	 */
>> +	BUG_ON(current->mm != mm);
>> +	if (is_32bit_task())
>> +		vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
>> +	else
>> +		vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
>> +#else
>> +	vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
>> +#endif
>> +	vdso_end += (1<<PAGE_SHIFT); /* data page */
>> +
>> +	/* Check if the vDSO is in the range of the remapped area */
>> +	if ((vdso_start <= old_start && old_start < vdso_end) ||
>> +	    (vdso_start < old_end && old_end <= vdso_end)  ||
>> +	    (old_start <= vdso_start && vdso_start < old_end)) {
>> +		/* Update vdso_base if the vDSO is entirely moved. */
>> +		if (old_start == vdso_start && old_end == vdso_end &&
>> +		    (old_end - old_start) == (new_end - new_start))
>> +			mm->context.vdso_base = new_start;
>> +		else
>> +			mm->context.vdso_base = 0;
>> +	}
>> +}
> 
> Oh my, that really looks awfully complex, as you predicted, and right 
> in every mremap() call.

I do agree, that's awfully complex ;)

> I'm fine with your original, imperfect, KISS approach. Sorry about 
> this detour ...
>
> Reviewed-by: Ingo Molnar <mingo@kernel.org>

No problem, so let's stay on the v3 version of the patch.
Thanks for Reviewed-by statement which, I guess, applied to the v3 too.
Should I resend the v3 ?

Thanks,
Laurent.

--
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>

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

[Benjamin Herrenschmidt]

On Thu, 2015-03-26 at 10:43 +0100, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > > * Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
> > > > > +{
> > > > > +	/*
> > > > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > > > +	 * check to old_start == vdso_base.
> > > > > +	 */
> > > > > +	if (old_start == mm->context.vdso_base)
> > > > > +		mm->context.vdso_base = new_start;
> > > > > +}
> > > > 
> > > > mremap() doesn't allow moving multiple vmas, but it allows the 
> > > > movement of multi-page vmas and it also allows partial mremap()s, 
> > > > where it will split up a vma.
> > > 
> > > I.e. mremap() supports the shrinking (and growing) of vmas. In that 
> > > case mremap() will unmap the end of the vma and will shrink the 
> > > remaining vDSO vma.
> > > 
> > > Doesn't that result in a non-working vDSO that should zero out 
> > > vdso_base?
> > 
> > Right. Now we can't completely prevent the user from shooting itself 
> > in the foot I suppose, though there is a legit usage scenario which 
> > is to move the vDSO around which it would be nice to support. I 
> > think it's reasonable to put the onus on the user here to do the 
> > right thing.
> 
> 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 the vDSO is OK, or 
> don't ...

Well, if we are going to clear it at all yes, we should probably be a
bit smarter about it. My point however was we probably don't need to be
super robust about dealing with any crazy scenario userspace might
conceive.

> There's also the question of mprotect(): can users mprotect() the vDSO 
> on PowerPC?

Nothing prevents it. But here too, I wouldn't bother. The user might be
doing on purpose expecting to catch the resulting signal for example
(though arguably a signal from a sigreturn frame is ... odd).

Cheers,
Ben.

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

[Benjamin Herrenschmidt]

On Thu, 2015-03-26 at 10:43 +0100, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > > * Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
> > > > > +{
> > > > > +	/*
> > > > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > > > +	 * check to old_start == vdso_base.
> > > > > +	 */
> > > > > +	if (old_start == mm->context.vdso_base)
> > > > > +		mm->context.vdso_base = new_start;
> > > > > +}
> > > > 
> > > > mremap() doesn't allow moving multiple vmas, but it allows the 
> > > > movement of multi-page vmas and it also allows partial mremap()s, 
> > > > where it will split up a vma.
> > > 
> > > I.e. mremap() supports the shrinking (and growing) of vmas. In that 
> > > case mremap() will unmap the end of the vma and will shrink the 
> > > remaining vDSO vma.
> > > 
> > > Doesn't that result in a non-working vDSO that should zero out 
> > > vdso_base?
> > 
> > Right. Now we can't completely prevent the user from shooting itself 
> > in the foot I suppose, though there is a legit usage scenario which 
> > is to move the vDSO around which it would be nice to support. I 
> > think it's reasonable to put the onus on the user here to do the 
> > right thing.
> 
> 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 the vDSO is OK, or 
> don't ...

Well, if we are going to clear it at all yes, we should probably be a
bit smarter about it. My point however was we probably don't need to be
super robust about dealing with any crazy scenario userspace might
conceive.

> There's also the question of mprotect(): can users mprotect() the vDSO 
> on PowerPC?

Nothing prevents it. But here too, I wouldn't bother. The user might be
doing on purpose expecting to catch the resulting signal for example
(though arguably a signal from a sigreturn frame is ... odd).

Cheers,
Ben.

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Benjamin Herrenschmidt]

On Thu, 2015-03-26 at 10:43 +0100, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > > * Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
> > > > > +{
> > > > > +	/*
> > > > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > > > +	 * check to old_start == vdso_base.
> > > > > +	 */
> > > > > +	if (old_start == mm->context.vdso_base)
> > > > > +		mm->context.vdso_base = new_start;
> > > > > +}
> > > > 
> > > > mremap() doesn't allow moving multiple vmas, but it allows the 
> > > > movement of multi-page vmas and it also allows partial mremap()s, 
> > > > where it will split up a vma.
> > > 
> > > I.e. mremap() supports the shrinking (and growing) of vmas. In that 
> > > case mremap() will unmap the end of the vma and will shrink the 
> > > remaining vDSO vma.
> > > 
> > > Doesn't that result in a non-working vDSO that should zero out 
> > > vdso_base?
> > 
> > Right. Now we can't completely prevent the user from shooting itself 
> > in the foot I suppose, though there is a legit usage scenario which 
> > is to move the vDSO around which it would be nice to support. I 
> > think it's reasonable to put the onus on the user here to do the 
> > right thing.
> 
> 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 the vDSO is OK, or 
> don't ...

Well, if we are going to clear it at all yes, we should probably be a
bit smarter about it. My point however was we probably don't need to be
super robust about dealing with any crazy scenario userspace might
conceive.

> There's also the question of mprotect(): can users mprotect() the vDSO 
> on PowerPC?

Nothing prevents it. But here too, I wouldn't bother. The user might be
doing on purpose expecting to catch the resulting signal for example
(though arguably a signal from a sigreturn frame is ... odd).

Cheers,
Ben.

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

[Benjamin Herrenschmidt]

On Thu, 2015-03-26 at 10:43 +0100, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > > * Ingo Molnar <mingo@kernel.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 new_start, unsigned long new_end)
> > > > > +{
> > > > > +	/*
> > > > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > > > +	 * check to old_start == vdso_base.
> > > > > +	 */
> > > > > +	if (old_start == mm->context.vdso_base)
> > > > > +		mm->context.vdso_base = new_start;
> > > > > +}
> > > > 
> > > > mremap() doesn't allow moving multiple vmas, but it allows the 
> > > > movement of multi-page vmas and it also allows partial mremap()s, 
> > > > where it will split up a vma.
> > > 
> > > I.e. mremap() supports the shrinking (and growing) of vmas. In that 
> > > case mremap() will unmap the end of the vma and will shrink the 
> > > remaining vDSO vma.
> > > 
> > > Doesn't that result in a non-working vDSO that should zero out 
> > > vdso_base?
> > 
> > Right. Now we can't completely prevent the user from shooting itself 
> > in the foot I suppose, though there is a legit usage scenario which 
> > is to move the vDSO around which it would be nice to support. I 
> > think it's reasonable to put the onus on the user here to do the 
> > right thing.
> 
> 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 the vDSO is OK, or 
> don't ...

Well, if we are going to clear it at all yes, we should probably be a
bit smarter about it. My point however was we probably don't need to be
super robust about dealing with any crazy scenario userspace might
conceive.

> There's also the question of mprotect(): can users mprotect() the vDSO 
> on PowerPC?

Nothing prevents it. But here too, I wouldn't bother. The user might be
doing on purpose expecting to catch the resulting signal for example
(though arguably a signal from a sigreturn frame is ... odd).

Cheers,
Ben.

--
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>

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

[Benjamin Herrenschmidt]

On Wed, 2015-03-25 at 19:33 +0100, Ingo Molnar wrote:
> * Laurent Dufour <ldufour@linux.vnet.ibm.com> wrote:
> 
> > +static inline void arch_unmap(struct mm_struct *mm,
> > +			struct vm_area_struct *vma,
> > +			unsigned long start, unsigned long end)
> > +{
> > +	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> > +		mm->context.vdso_base = 0;
> > +}
> 
> So AFAICS PowerPC can have multi-page vDSOs, right?
> 
> So what happens if I munmap() the middle or end of the vDSO? The above 
> condition only seems to cover unmaps that affect the first page. I 
> think 'affects any page' ought to be the right condition? (But I know 
> nothing about PowerPC so I might be wrong.)

You are right, we have at least two pages.
> 
> > +#define __HAVE_ARCH_REMAP
> > +static inline void arch_remap(struct mm_struct *mm,
> > +			      unsigned long old_start, unsigned long old_end,
> > +			      unsigned long new_start, unsigned long new_end)
> > +{
> > +	/*
> > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > +	 * check to old_start == vdso_base.
> > +	 */
> > +	if (old_start == mm->context.vdso_base)
> > +		mm->context.vdso_base = new_start;
> > +}
> 
> mremap() doesn't allow moving multiple vmas, but it allows the 
> movement of multi-page vmas and it also allows partial mremap()s, 
> where it will split up a vma.
> 
> In particular, what happens if an mremap() is done with 
> old_start == vdso_base, but a shorter end than the end of the vDSO? 
> (i.e. a partial mremap() with fewer pages than the vDSO size)

Is there a way to forbid splitting ? Does x86 deal with that case at all
or it doesn't have to for some other reason ?

Cheers,
Ben.

> Thanks,
> 
> 	Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Benjamin Herrenschmidt]

On Wed, 2015-03-25 at 19:33 +0100, Ingo Molnar wrote:
> * Laurent Dufour <ldufour@linux.vnet.ibm.com> wrote:
> 
> > +static inline void arch_unmap(struct mm_struct *mm,
> > +			struct vm_area_struct *vma,
> > +			unsigned long start, unsigned long end)
> > +{
> > +	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> > +		mm->context.vdso_base = 0;
> > +}
> 
> So AFAICS PowerPC can have multi-page vDSOs, right?
> 
> So what happens if I munmap() the middle or end of the vDSO? The above 
> condition only seems to cover unmaps that affect the first page. I 
> think 'affects any page' ought to be the right condition? (But I know 
> nothing about PowerPC so I might be wrong.)

You are right, we have at least two pages.
> 
> > +#define __HAVE_ARCH_REMAP
> > +static inline void arch_remap(struct mm_struct *mm,
> > +			      unsigned long old_start, unsigned long old_end,
> > +			      unsigned long new_start, unsigned long new_end)
> > +{
> > +	/*
> > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > +	 * check to old_start == vdso_base.
> > +	 */
> > +	if (old_start == mm->context.vdso_base)
> > +		mm->context.vdso_base = new_start;
> > +}
> 
> mremap() doesn't allow moving multiple vmas, but it allows the 
> movement of multi-page vmas and it also allows partial mremap()s, 
> where it will split up a vma.
> 
> In particular, what happens if an mremap() is done with 
> old_start == vdso_base, but a shorter end than the end of the vDSO? 
> (i.e. a partial mremap() with fewer pages than the vDSO size)

Is there a way to forbid splitting ? Does x86 deal with that case at all
or it doesn't have to for some other reason ?

Cheers,
Ben.

> Thanks,
> 
> 	Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Benjamin Herrenschmidt]

On Wed, 2015-03-25 at 19:33 +0100, Ingo Molnar wrote:
> * Laurent Dufour <ldufour@linux.vnet.ibm.com> wrote:
> 
> > +static inline void arch_unmap(struct mm_struct *mm,
> > +			struct vm_area_struct *vma,
> > +			unsigned long start, unsigned long end)
> > +{
> > +	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> > +		mm->context.vdso_base = 0;
> > +}
> 
> So AFAICS PowerPC can have multi-page vDSOs, right?
> 
> So what happens if I munmap() the middle or end of the vDSO? The above 
> condition only seems to cover unmaps that affect the first page. I 
> think 'affects any page' ought to be the right condition? (But I know 
> nothing about PowerPC so I might be wrong.)

You are right, we have at least two pages.
> 
> > +#define __HAVE_ARCH_REMAP
> > +static inline void arch_remap(struct mm_struct *mm,
> > +			      unsigned long old_start, unsigned long old_end,
> > +			      unsigned long new_start, unsigned long new_end)
> > +{
> > +	/*
> > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > +	 * check to old_start == vdso_base.
> > +	 */
> > +	if (old_start == mm->context.vdso_base)
> > +		mm->context.vdso_base = new_start;
> > +}
> 
> mremap() doesn't allow moving multiple vmas, but it allows the 
> movement of multi-page vmas and it also allows partial mremap()s, 
> where it will split up a vma.
> 
> In particular, what happens if an mremap() is done with 
> old_start == vdso_base, but a shorter end than the end of the vDSO? 
> (i.e. a partial mremap() with fewer pages than the vDSO size)

Is there a way to forbid splitting ? Does x86 deal with that case at all
or it doesn't have to for some other reason ?

Cheers,
Ben.

> Thanks,
> 
> 	Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Benjamin Herrenschmidt]

On Wed, 2015-03-25 at 19:33 +0100, Ingo Molnar wrote:
> * Laurent Dufour <ldufour@linux.vnet.ibm.com> wrote:
> 
> > +static inline void arch_unmap(struct mm_struct *mm,
> > +			struct vm_area_struct *vma,
> > +			unsigned long start, unsigned long end)
> > +{
> > +	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> > +		mm->context.vdso_base = 0;
> > +}
> 
> So AFAICS PowerPC can have multi-page vDSOs, right?
> 
> So what happens if I munmap() the middle or end of the vDSO? The above 
> condition only seems to cover unmaps that affect the first page. I 
> think 'affects any page' ought to be the right condition? (But I know 
> nothing about PowerPC so I might be wrong.)

You are right, we have at least two pages.
> 
> > +#define __HAVE_ARCH_REMAP
> > +static inline void arch_remap(struct mm_struct *mm,
> > +			      unsigned long old_start, unsigned long old_end,
> > +			      unsigned long new_start, unsigned long new_end)
> > +{
> > +	/*
> > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > +	 * check to old_start == vdso_base.
> > +	 */
> > +	if (old_start == mm->context.vdso_base)
> > +		mm->context.vdso_base = new_start;
> > +}
> 
> mremap() doesn't allow moving multiple vmas, but it allows the 
> movement of multi-page vmas and it also allows partial mremap()s, 
> where it will split up a vma.
> 
> In particular, what happens if an mremap() is done with 
> old_start == vdso_base, but a shorter end than the end of the vDSO? 
> (i.e. a partial mremap() with fewer pages than the vDSO size)

Is there a way to forbid splitting ? Does x86 deal with that case at all
or it doesn't have to for some other reason ?

Cheers,
Ben.

> Thanks,
> 
> 	Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


--
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>

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

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@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 new_start, unsigned long new_end)
> > > +{
> > > +	/*
> > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > +	 * check to old_start == vdso_base.
> > > +	 */
> > > +	if (old_start == mm->context.vdso_base)
> > > +		mm->context.vdso_base = new_start;
> > > +}
> > 
> > mremap() doesn't allow moving multiple vmas, but it allows the 
> > movement of multi-page vmas and it also allows partial mremap()s, 
> > where it will split up a vma.
> > 
> > In particular, what happens if an mremap() is done with 
> > old_start == vdso_base, but a shorter end than the end of the vDSO? 
> > (i.e. a partial mremap() with fewer pages than the vDSO size)
> 
> Is there a way to forbid splitting ? Does x86 deal with that case at 
> all or it doesn't have to for some other reason ?

So we use _install_special_mapping() - maybe PowerPC does that too? 
That adds VM_DONTEXPAND which ought to prevent some - but not all - of 
the VM API weirdnesses.

On x86 we'll just dump core if someone unmaps the vdso.

Thanks,

	Ingo

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

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@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 new_start, unsigned long new_end)
> > > +{
> > > +	/*
> > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > +	 * check to old_start == vdso_base.
> > > +	 */
> > > +	if (old_start == mm->context.vdso_base)
> > > +		mm->context.vdso_base = new_start;
> > > +}
> > 
> > mremap() doesn't allow moving multiple vmas, but it allows the 
> > movement of multi-page vmas and it also allows partial mremap()s, 
> > where it will split up a vma.
> > 
> > In particular, what happens if an mremap() is done with 
> > old_start == vdso_base, but a shorter end than the end of the vDSO? 
> > (i.e. a partial mremap() with fewer pages than the vDSO size)
> 
> Is there a way to forbid splitting ? Does x86 deal with that case at 
> all or it doesn't have to for some other reason ?

So we use _install_special_mapping() - maybe PowerPC does that too? 
That adds VM_DONTEXPAND which ought to prevent some - but not all - of 
the VM API weirdnesses.

On x86 we'll just dump core if someone unmaps the vdso.

Thanks,

	Ingo

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

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@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 new_start, unsigned long new_end)
> > > +{
> > > +	/*
> > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > +	 * check to old_start == vdso_base.
> > > +	 */
> > > +	if (old_start == mm->context.vdso_base)
> > > +		mm->context.vdso_base = new_start;
> > > +}
> > 
> > mremap() doesn't allow moving multiple vmas, but it allows the 
> > movement of multi-page vmas and it also allows partial mremap()s, 
> > where it will split up a vma.
> > 
> > In particular, what happens if an mremap() is done with 
> > old_start == vdso_base, but a shorter end than the end of the vDSO? 
> > (i.e. a partial mremap() with fewer pages than the vDSO size)
> 
> Is there a way to forbid splitting ? Does x86 deal with that case at 
> all or it doesn't have to for some other reason ?

So we use _install_special_mapping() - maybe PowerPC does that too? 
That adds VM_DONTEXPAND which ought to prevent some - but not all - of 
the VM API weirdnesses.

On x86 we'll just dump core if someone unmaps the vdso.

Thanks,

	Ingo

--
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>

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

[Laurent Dufour]

On 26/03/2015 10:48, Ingo Molnar wrote:
> 
> * Benjamin Herrenschmidt <benh@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 new_start, unsigned long new_end)
>>>> +{
>>>> +	/*
>>>> +	 * mremap() doesn't allow moving multiple vmas so we can limit the
>>>> +	 * check to old_start == vdso_base.
>>>> +	 */
>>>> +	if (old_start == mm->context.vdso_base)
>>>> +		mm->context.vdso_base = new_start;
>>>> +}
>>>
>>> mremap() doesn't allow moving multiple vmas, but it allows the 
>>> movement of multi-page vmas and it also allows partial mremap()s, 
>>> where it will split up a vma.
>>>
>>> In particular, what happens if an mremap() is done with 
>>> old_start == vdso_base, but a shorter end than the end of the vDSO? 
>>> (i.e. a partial mremap() with fewer pages than the vDSO size)
>>
>> Is there a way to forbid splitting ? Does x86 deal with that case at 
>> all or it doesn't have to for some other reason ?
> 
> So we use _install_special_mapping() - maybe PowerPC does that too? 
> That adds VM_DONTEXPAND which ought to prevent some - but not all - of 
> the VM API weirdnesses.

The same is done on PowerPC. So calling mremap() to extend the vDSO is
failing but splitting it or unmapping a part of it is allowed but lead
to an unusable vDSO.

> On x86 we'll just dump core if someone unmaps the vdso.

On PowerPC, you'll get the same result.

Should we prevent the user to break its vDSO ?

Thanks,
Laurent.

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

[Laurent Dufour]

On 26/03/2015 10:48, Ingo Molnar wrote:
> 
> * Benjamin Herrenschmidt <benh@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 new_start, unsigned long new_end)
>>>> +{
>>>> +	/*
>>>> +	 * mremap() doesn't allow moving multiple vmas so we can limit the
>>>> +	 * check to old_start == vdso_base.
>>>> +	 */
>>>> +	if (old_start == mm->context.vdso_base)
>>>> +		mm->context.vdso_base = new_start;
>>>> +}
>>>
>>> mremap() doesn't allow moving multiple vmas, but it allows the 
>>> movement of multi-page vmas and it also allows partial mremap()s, 
>>> where it will split up a vma.
>>>
>>> In particular, what happens if an mremap() is done with 
>>> old_start == vdso_base, but a shorter end than the end of the vDSO? 
>>> (i.e. a partial mremap() with fewer pages than the vDSO size)
>>
>> Is there a way to forbid splitting ? Does x86 deal with that case at 
>> all or it doesn't have to for some other reason ?
> 
> So we use _install_special_mapping() - maybe PowerPC does that too? 
> That adds VM_DONTEXPAND which ought to prevent some - but not all - of 
> the VM API weirdnesses.

The same is done on PowerPC. So calling mremap() to extend the vDSO is
failing but splitting it or unmapping a part of it is allowed but lead
to an unusable vDSO.

> On x86 we'll just dump core if someone unmaps the vdso.

On PowerPC, you'll get the same result.

Should we prevent the user to break its vDSO ?

Thanks,
Laurent.

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

[Laurent Dufour]

On 26/03/2015 10:48, Ingo Molnar wrote:
> 
> * Benjamin Herrenschmidt <benh@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 new_start, unsigned long new_end)
>>>> +{
>>>> +	/*
>>>> +	 * mremap() doesn't allow moving multiple vmas so we can limit the
>>>> +	 * check to old_start == vdso_base.
>>>> +	 */
>>>> +	if (old_start == mm->context.vdso_base)
>>>> +		mm->context.vdso_base = new_start;
>>>> +}
>>>
>>> mremap() doesn't allow moving multiple vmas, but it allows the 
>>> movement of multi-page vmas and it also allows partial mremap()s, 
>>> where it will split up a vma.
>>>
>>> In particular, what happens if an mremap() is done with 
>>> old_start == vdso_base, but a shorter end than the end of the vDSO? 
>>> (i.e. a partial mremap() with fewer pages than the vDSO size)
>>
>> Is there a way to forbid splitting ? Does x86 deal with that case at 
>> all or it doesn't have to for some other reason ?
> 
> So we use _install_special_mapping() - maybe PowerPC does that too? 
> That adds VM_DONTEXPAND which ought to prevent some - but not all - of 
> the VM API weirdnesses.

The same is done on PowerPC. So calling mremap() to extend the vDSO is
failing but splitting it or unmapping a part of it is allowed but lead
to an unusable vDSO.

> On x86 we'll just dump core if someone unmaps the vdso.

On PowerPC, you'll get the same result.

Should we prevent the user to break its vDSO ?

Thanks,
Laurent.

--
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>

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

[Laurent Dufour]

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 the vDSO has been
moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.

Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
index 73382eba02dc..ce7fc93518ee 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*
@@ -109,5 +108,39 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
 #endif
 }
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				 struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+static inline void arch_unmap(struct mm_struct *mm,
+			struct vm_area_struct *vma,
+			unsigned long start, unsigned long end)
+{
+	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
+		mm->context.vdso_base = 0;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	/*
+	 * mremap don't allow moving multiple vma so we can limit the check
+	 * to old_start == vdso_base.
+	 */
+	if (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
-- 
1.9.1

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

[Laurent Dufour]

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 the vDSO has been
moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.

Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
index 73382eba02dc..ce7fc93518ee 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*
@@ -109,5 +108,39 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
 #endif
 }
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				 struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+static inline void arch_unmap(struct mm_struct *mm,
+			struct vm_area_struct *vma,
+			unsigned long start, unsigned long end)
+{
+	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
+		mm->context.vdso_base = 0;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	/*
+	 * mremap don't allow moving multiple vma so we can limit the check
+	 * to old_start == vdso_base.
+	 */
+	if (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
-- 
1.9.1

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

[Laurent Dufour]

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 the vDSO has been
moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.

Signed-off-by: Laurent Dufour <ldufour@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/mmu_context.h
index 73382eba02dc..ce7fc93518ee 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*
@@ -109,5 +108,39 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
 #endif
 }
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				 struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+static inline void arch_unmap(struct mm_struct *mm,
+			struct vm_area_struct *vma,
+			unsigned long start, unsigned long end)
+{
+	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
+		mm->context.vdso_base = 0;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	/*
+	 * mremap don't allow moving multiple vma so we can limit the check
+	 * to old_start == vdso_base.
+	 */
+	if (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
-- 
1.9.1

--
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>

Re: [PATCH 0/2] Tracking user space vDSO remaping

[Christopher Covington]

Hi,

On 03/20/2015 11:53 AM, Laurent Dufour wrote:
> CRIU is recreating the process memory layout by remapping the checkpointee
> memory area on top of the current process (criu). This includes remapping
> the vDSO to the place it has at checkpoint time.
> 
> However some architectures like powerpc are keeping a reference to the vDSO
> base address to build the signal return stack frame by calling the vDSO
> sigreturn service. So once the vDSO has been moved, this reference is no
> more valid and the signal frame built later are not usable.
> 
> This patch serie is introducing a new mm hook 'arch_remap' which is called
> when mremap is done and the mm lock still 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      |  6 ++++++
>  arch/um/include/asm/mmu_context.h        |  5 +++++
>  arch/unicore32/include/asm/mmu_context.h |  6 ++++++
>  arch/x86/include/asm/mmu_context.h       |  6 ++++++
>  include/asm-generic/mm_hooks.h           |  6 ++++++
>  mm/mremap.c                              |  9 ++++++--
>  7 files changed, 70 insertions(+), 3 deletions(-)

We would like to be able to remap/unmap the VDSO on arm and arm64 as
well. When I proposed a patch with mmu_context.h and mmu-arch-hooks.h
changes to arm64 that were nearly identical to those done to powerpc,
Will Deacon reasonably suggested [1] attempting to combine the code and
provide generic VDSO accessors. Unfortunately, I no prior experience
with generic MM code. Can anyone advise on how to get started with that?

1. http://www.spinics.net/lists/linux-arm-msm/msg18441.html

Thanks,
Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 0/2] Tracking user space vDSO remaping

[Christopher Covington]

Hi,

On 03/20/2015 11:53 AM, Laurent Dufour wrote:
> CRIU is recreating the process memory layout by remapping the checkpointee
> memory area on top of the current process (criu). This includes remapping
> the vDSO to the place it has at checkpoint time.
> 
> However some architectures like powerpc are keeping a reference to the vDSO
> base address to build the signal return stack frame by calling the vDSO
> sigreturn service. So once the vDSO has been moved, this reference is no
> more valid and the signal frame built later are not usable.
> 
> This patch serie is introducing a new mm hook 'arch_remap' which is called
> when mremap is done and the mm lock still 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      |  6 ++++++
>  arch/um/include/asm/mmu_context.h        |  5 +++++
>  arch/unicore32/include/asm/mmu_context.h |  6 ++++++
>  arch/x86/include/asm/mmu_context.h       |  6 ++++++
>  include/asm-generic/mm_hooks.h           |  6 ++++++
>  mm/mremap.c                              |  9 ++++++--
>  7 files changed, 70 insertions(+), 3 deletions(-)

We would like to be able to remap/unmap the VDSO on arm and arm64 as
well. When I proposed a patch with mmu_context.h and mmu-arch-hooks.h
changes to arm64 that were nearly identical to those done to powerpc,
Will Deacon reasonably suggested [1] attempting to combine the code and
provide generic VDSO accessors. Unfortunately, I no prior experience
with generic MM code. Can anyone advise on how to get started with that?

1. http://www.spinics.net/lists/linux-arm-msm/msg18441.html

Thanks,
Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 0/2] Tracking user space vDSO remaping

[Christopher Covington]

Hi,

On 03/20/2015 11:53 AM, Laurent Dufour wrote:
> CRIU is recreating the process memory layout by remapping the checkpointee
> memory area on top of the current process (criu). This includes remapping
> the vDSO to the place it has at checkpoint time.
> 
> However some architectures like powerpc are keeping a reference to the vDSO
> base address to build the signal return stack frame by calling the vDSO
> sigreturn service. So once the vDSO has been moved, this reference is no
> more valid and the signal frame built later are not usable.
> 
> This patch serie is introducing a new mm hook 'arch_remap' which is called
> when mremap is done and the mm lock still 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      |  6 ++++++
>  arch/um/include/asm/mmu_context.h        |  5 +++++
>  arch/unicore32/include/asm/mmu_context.h |  6 ++++++
>  arch/x86/include/asm/mmu_context.h       |  6 ++++++
>  include/asm-generic/mm_hooks.h           |  6 ++++++
>  mm/mremap.c                              |  9 ++++++--
>  7 files changed, 70 insertions(+), 3 deletions(-)

We would like to be able to remap/unmap the VDSO on arm and arm64 as
well. When I proposed a patch with mmu_context.h and mmu-arch-hooks.h
changes to arm64 that were nearly identical to those done to powerpc,
Will Deacon reasonably suggested [1] attempting to combine the code and
provide generic VDSO accessors. Unfortunately, I no prior experience
with generic MM code. Can anyone advise on how to get started with that?

1. http://www.spinics.net/lists/linux-arm-msm/msg18441.html

Thanks,
Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 0/2] Tracking user space vDSO remaping

[Christopher Covington]

Hi,

On 03/20/2015 11:53 AM, Laurent Dufour wrote:
> CRIU is recreating the process memory layout by remapping the checkpointee
> memory area on top of the current process (criu). This includes remapping
> the vDSO to the place it has at checkpoint time.
> 
> However some architectures like powerpc are keeping a reference to the vDSO
> base address to build the signal return stack frame by calling the vDSO
> sigreturn service. So once the vDSO has been moved, this reference is no
> more valid and the signal frame built later are not usable.
> 
> This patch serie is introducing a new mm hook 'arch_remap' which is called
> when mremap is done and the mm lock still 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      |  6 ++++++
>  arch/um/include/asm/mmu_context.h        |  5 +++++
>  arch/unicore32/include/asm/mmu_context.h |  6 ++++++
>  arch/x86/include/asm/mmu_context.h       |  6 ++++++
>  include/asm-generic/mm_hooks.h           |  6 ++++++
>  mm/mremap.c                              |  9 ++++++--
>  7 files changed, 70 insertions(+), 3 deletions(-)

We would like to be able to remap/unmap the VDSO on arm and arm64 as
well. When I proposed a patch with mmu_context.h and mmu-arch-hooks.h
changes to arm64 that were nearly identical to those done to powerpc,
Will Deacon reasonably suggested [1] attempting to combine the code and
provide generic VDSO accessors. Unfortunately, I no prior experience
with generic MM code. Can anyone advise on how to get started with that?

1. http://www.spinics.net/lists/linux-arm-msm/msg18441.html

Thanks,
Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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>