linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] arm64: Support VDSO remapping
@ 2015-11-25 12:49 Christopher Covington
  2015-12-02 12:19 ` Will Deacon
  0 siblings, 1 reply; 15+ messages in thread
From: Christopher Covington @ 2015-11-25 12:49 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon, linux-arm-kernel
  Cc: linux-arm-msm, Christopher Covington, Jens Axboe, Andrew Morton,
	Jason Cooper, Laurent Dufour, Daniel Borkmann, Marc Zyngier,
	Ingo Molnar, Ard Biesheuvel, Mark Rutland, linux-kernel

Some applications such as Checkpoint/Restore In Userspace (CRIU) remap and
unmap the VDSO. Add support for this to the AArch64 kernel by copying in
the PowerPC code with slight modifications.

Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
 arch/arm64/include/asm/Kbuild          |  1 -
 arch/arm64/include/asm/mm-arch-hooks.h | 28 ++++++++++++++++++++++++++++
 arch/arm64/include/asm/mmu_context.h   | 23 ++++++++++++++++++++++-
 3 files changed, 50 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/include/asm/mm-arch-hooks.h

diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 70fd9ff..b112a39 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -25,7 +25,6 @@ generic-y += kvm_para.h
 generic-y += local.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
-generic-y += mm-arch-hooks.h
 generic-y += mman.h
 generic-y += msgbuf.h
 generic-y += msi.h
diff --git a/arch/arm64/include/asm/mm-arch-hooks.h b/arch/arm64/include/asm/mm-arch-hooks.h
new file mode 100644
index 0000000..e6923fb
--- /dev/null
+++ b/arch/arm64/include/asm/mm-arch-hooks.h
@@ -0,0 +1,28 @@
+/*
+ * Architecture specific mm hooks
+ *
+ * Copyright (C) 2015, IBM Corporation
+ * Author: Laurent Dufour <ldufour@linux.vnet.ibm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_MM_ARCH_HOOKS_H
+#define __ASM_MM_ARCH_HOOKS_H
+
+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 ((void *)old_start == mm->context.vdso)
+		mm->context.vdso = (void *)new_start;
+}
+#define arch_remap arch_remap
+
+#endif /* __ASM_MM_ARCH_HOOKS_H */
diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index 2416578..9fe0773 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -24,7 +24,6 @@
 
 #include <asm/cacheflush.h>
 #include <asm/proc-fns.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputype.h>
 #include <asm/pgtable.h>
 
@@ -147,4 +146,26 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
 #define deactivate_mm(tsk,mm)	do { } while (0)
 #define activate_mm(prev,next)	switch_mm(prev, next, NULL)
 
+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 ((void *)start <= mm->context.vdso && mm->context.vdso < (void *)end)
+		mm->context.vdso = NULL;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
 #endif
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH] arm64: Support VDSO remapping
  2015-11-25 12:49 [PATCH] arm64: Support VDSO remapping Christopher Covington
@ 2015-12-02 12:19 ` Will Deacon
  2015-12-03 18:05   ` Christopher Covington
  2016-04-28 15:18   ` VDSO unmap and remap support for additional architectures Christopher Covington
  0 siblings, 2 replies; 15+ messages in thread
From: Will Deacon @ 2015-12-02 12:19 UTC (permalink / raw)
  To: Christopher Covington
  Cc: Catalin Marinas, linux-arm-kernel, linux-arm-msm, Jens Axboe,
	Andrew Morton, Jason Cooper, Laurent Dufour, Daniel Borkmann,
	Marc Zyngier, Ingo Molnar, Ard Biesheuvel, Mark Rutland,
	linux-kernel

Hi Christopher,

On Wed, Nov 25, 2015 at 07:49:29AM -0500, Christopher Covington wrote:
> Some applications such as Checkpoint/Restore In Userspace (CRIU) remap and
> unmap the VDSO. Add support for this to the AArch64 kernel by copying in
> the PowerPC code with slight modifications.
> 
> Signed-off-by: Christopher Covington <cov@codeaurora.org>
> ---
>  arch/arm64/include/asm/Kbuild          |  1 -
>  arch/arm64/include/asm/mm-arch-hooks.h | 28 ++++++++++++++++++++++++++++
>  arch/arm64/include/asm/mmu_context.h   | 23 ++++++++++++++++++++++-
>  3 files changed, 50 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm64/include/asm/mm-arch-hooks.h
> 
> diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
> index 70fd9ff..b112a39 100644
> --- a/arch/arm64/include/asm/Kbuild
> +++ b/arch/arm64/include/asm/Kbuild
> @@ -25,7 +25,6 @@ generic-y += kvm_para.h
>  generic-y += local.h
>  generic-y += local64.h
>  generic-y += mcs_spinlock.h
> -generic-y += mm-arch-hooks.h
>  generic-y += mman.h
>  generic-y += msgbuf.h
>  generic-y += msi.h
> diff --git a/arch/arm64/include/asm/mm-arch-hooks.h b/arch/arm64/include/asm/mm-arch-hooks.h
> new file mode 100644
> index 0000000..e6923fb
> --- /dev/null
> +++ b/arch/arm64/include/asm/mm-arch-hooks.h
> @@ -0,0 +1,28 @@
> +/*
> + * Architecture specific mm hooks
> + *
> + * Copyright (C) 2015, IBM Corporation
> + * Author: Laurent Dufour <ldufour@linux.vnet.ibm.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __ASM_MM_ARCH_HOOKS_H
> +#define __ASM_MM_ARCH_HOOKS_H
> +
> +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 ((void *)old_start == mm->context.vdso)
> +		mm->context.vdso = (void *)new_start;
> +}
> +#define arch_remap arch_remap
> +
> +#endif /* __ASM_MM_ARCH_HOOKS_H */
> diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
> index 2416578..9fe0773 100644
> --- a/arch/arm64/include/asm/mmu_context.h
> +++ b/arch/arm64/include/asm/mmu_context.h
> @@ -24,7 +24,6 @@
>  
>  #include <asm/cacheflush.h>
>  #include <asm/proc-fns.h>
> -#include <asm-generic/mm_hooks.h>
>  #include <asm/cputype.h>
>  #include <asm/pgtable.h>
>  
> @@ -147,4 +146,26 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
>  #define deactivate_mm(tsk,mm)	do { } while (0)
>  #define activate_mm(prev,next)	switch_mm(prev, next, NULL)
>  
> +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 ((void *)start <= mm->context.vdso && mm->context.vdso < (void *)end)
> +		mm->context.vdso = NULL;
> +}
> +
> +static inline void arch_bprm_mm_init(struct mm_struct *mm,
> +				     struct vm_area_struct *vma)
> +{
> +}

This is virtually identical to the PowerPC implementation, afaict. Any
chance we could move this to core code and define some generic vdso
accessors for the mm?

Will

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] arm64: Support VDSO remapping
  2015-12-02 12:19 ` Will Deacon
@ 2015-12-03 18:05   ` Christopher Covington
  2016-04-28 15:18   ` VDSO unmap and remap support for additional architectures Christopher Covington
  1 sibling, 0 replies; 15+ messages in thread
From: Christopher Covington @ 2015-12-03 18:05 UTC (permalink / raw)
  To: Will Deacon
  Cc: Mark Rutland, Jason Cooper, Ard Biesheuvel, Marc Zyngier,
	Catalin Marinas, linux-kernel, Jens Axboe, Daniel Borkmann,
	linux-arm-msm, Andrew Morton, Laurent Dufour, Ingo Molnar,
	linux-arm-kernel

On 12/02/2015 07:19 AM, Will Deacon wrote:
> Hi Christopher,
> 
> On Wed, Nov 25, 2015 at 07:49:29AM -0500, Christopher Covington wrote:
>> Some applications such as Checkpoint/Restore In Userspace (CRIU) remap and
>> unmap the VDSO. Add support for this to the AArch64 kernel by copying in
>> the PowerPC code with slight modifications.
>>
>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
>> ---
>>  arch/arm64/include/asm/Kbuild          |  1 -
>>  arch/arm64/include/asm/mm-arch-hooks.h | 28 ++++++++++++++++++++++++++++
>>  arch/arm64/include/asm/mmu_context.h   | 23 ++++++++++++++++++++++-
>>  3 files changed, 50 insertions(+), 2 deletions(-)
>>  create mode 100644 arch/arm64/include/asm/mm-arch-hooks.h
>>
>> diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
>> index 70fd9ff..b112a39 100644
>> --- a/arch/arm64/include/asm/Kbuild
>> +++ b/arch/arm64/include/asm/Kbuild
>> @@ -25,7 +25,6 @@ generic-y += kvm_para.h
>>  generic-y += local.h
>>  generic-y += local64.h
>>  generic-y += mcs_spinlock.h
>> -generic-y += mm-arch-hooks.h
>>  generic-y += mman.h
>>  generic-y += msgbuf.h
>>  generic-y += msi.h
>> diff --git a/arch/arm64/include/asm/mm-arch-hooks.h b/arch/arm64/include/asm/mm-arch-hooks.h
>> new file mode 100644
>> index 0000000..e6923fb
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/mm-arch-hooks.h
>> @@ -0,0 +1,28 @@
>> +/*
>> + * Architecture specific mm hooks
>> + *
>> + * Copyright (C) 2015, IBM Corporation
>> + * Author: Laurent Dufour <ldufour@linux.vnet.ibm.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#ifndef __ASM_MM_ARCH_HOOKS_H
>> +#define __ASM_MM_ARCH_HOOKS_H
>> +
>> +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 ((void *)old_start == mm->context.vdso)
>> +		mm->context.vdso = (void *)new_start;
>> +}
>> +#define arch_remap arch_remap
>> +
>> +#endif /* __ASM_MM_ARCH_HOOKS_H */
>> diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
>> index 2416578..9fe0773 100644
>> --- a/arch/arm64/include/asm/mmu_context.h
>> +++ b/arch/arm64/include/asm/mmu_context.h
>> @@ -24,7 +24,6 @@
>>  
>>  #include <asm/cacheflush.h>
>>  #include <asm/proc-fns.h>
>> -#include <asm-generic/mm_hooks.h>
>>  #include <asm/cputype.h>
>>  #include <asm/pgtable.h>
>>  
>> @@ -147,4 +146,26 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
>>  #define deactivate_mm(tsk,mm)	do { } while (0)
>>  #define activate_mm(prev,next)	switch_mm(prev, next, NULL)
>>  
>> +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 ((void *)start <= mm->context.vdso && mm->context.vdso < (void *)end)
>> +		mm->context.vdso = NULL;
>> +}
>> +
>> +static inline void arch_bprm_mm_init(struct mm_struct *mm,
>> +				     struct vm_area_struct *vma)
>> +{
>> +}
> 
> This is virtually identical to the PowerPC implementation, afaict. Any
> chance we could move this to core code and define some generic vdso
> accessors for the mm?

I think the same criticism applies to the VDSO code itself, and I'm not
sure how easy it is to provide common VDSO remap/unmap without common
VDSO code. I guess I'll do some investigating when I have then chance.

Thanks,
Christopher Covington

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* VDSO unmap and remap support for additional architectures
  2015-12-02 12:19 ` Will Deacon
  2015-12-03 18:05   ` Christopher Covington
@ 2016-04-28 15:18   ` Christopher Covington
  2016-04-28 15:18     ` [RFC 1/5] powerpc: Rename context.vdso_base to context.vdso Christopher Covington
                       ` (5 more replies)
  1 sibling, 6 replies; 15+ messages in thread
From: Christopher Covington @ 2016-04-28 15:18 UTC (permalink / raw)
  To: Catalin Marinas, criu, Laurent Dufour, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Arnd Bergmann, linux-arm-kernel, linux-kernel, linuxppc-dev,
	linux-arch, linux-mm

Please take a look at the following prototype of sharing the PowerPC
VDSO unmap and remap code with other architectures. I've only hooked
up arm64 to begin with. If folks think this is a reasonable approach I
can work on 32 bit ARM as well. Not hearing back from an earlier
request for guidance [1], I simply dove in and started hacking.
Laurent's test case [2][3] is a compelling illustration of whether VDSO
remap works or not on a given architecture.

1. https://lkml.org/lkml/2016/3/2/225
2. https://lists.openvz.org/pipermail/criu/2015-March/019161.html
3. http://lists.openvz.org/pipermail/criu/attachments/20150318/f02ed9ea/attachment.bin

Thanks,
Christopher Covington

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [RFC 1/5] powerpc: Rename context.vdso_base to context.vdso
  2016-04-28 15:18   ` VDSO unmap and remap support for additional architectures Christopher Covington
@ 2016-04-28 15:18     ` Christopher Covington
  2016-05-02  1:05       ` Balbir Singh
  2016-04-28 15:18     ` [RFC 2/5] mm/powerpc: Make VDSO unmap generic Christopher Covington
                       ` (4 subsequent siblings)
  5 siblings, 1 reply; 15+ messages in thread
From: Christopher Covington @ 2016-04-28 15:18 UTC (permalink / raw)
  To: Catalin Marinas, criu, Laurent Dufour, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Arnd Bergmann, linux-arm-kernel, linux-kernel, linuxppc-dev,
	linux-arch, linux-mm
  Cc: Christopher Covington

In order to share remap and unmap support for the VDSO with other
architectures without duplicating the code, we need a common name and type
for the address of the VDSO. An informal survey of the architectures
indicates unsigned long vdso is popular. Change the variable name in
powerpc from mm->context.vdso_base to simply mm->context.vdso.

Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
 arch/powerpc/include/asm/book3s/32/mmu-hash.h |  2 +-
 arch/powerpc/include/asm/book3s/64/mmu-hash.h |  2 +-
 arch/powerpc/include/asm/mm-arch-hooks.h      |  6 +++---
 arch/powerpc/include/asm/mmu-40x.h            |  2 +-
 arch/powerpc/include/asm/mmu-44x.h            |  2 +-
 arch/powerpc/include/asm/mmu-8xx.h            |  2 +-
 arch/powerpc/include/asm/mmu-book3e.h         |  2 +-
 arch/powerpc/include/asm/mmu_context.h        |  4 ++--
 arch/powerpc/include/asm/vdso.h               |  2 +-
 arch/powerpc/include/uapi/asm/elf.h           |  2 +-
 arch/powerpc/kernel/signal_32.c               |  8 ++++----
 arch/powerpc/kernel/signal_64.c               |  4 ++--
 arch/powerpc/kernel/vdso.c                    |  8 ++++----
 arch/powerpc/perf/callchain.c                 | 12 ++++++------
 14 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/32/mmu-hash.h b/arch/powerpc/include/asm/book3s/32/mmu-hash.h
index 16f513e..9d8de53 100644
--- a/arch/powerpc/include/asm/book3s/32/mmu-hash.h
+++ b/arch/powerpc/include/asm/book3s/32/mmu-hash.h
@@ -79,7 +79,7 @@ struct hash_pte {
 
 typedef struct {
 	unsigned long id;
-	unsigned long vdso_base;
+	unsigned long vdso;
 } mm_context_t;
 
 #endif /* !__ASSEMBLY__ */
diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
index 0cea480..99df600 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
@@ -525,7 +525,7 @@ typedef struct {
 #else
 	u16 sllp;		/* SLB page size encoding */
 #endif
-	unsigned long vdso_base;
+	unsigned long vdso;
 #ifdef CONFIG_PPC_SUBPAGE_PROT
 	struct subpage_prot_table spt;
 #endif /* CONFIG_PPC_SUBPAGE_PROT */
diff --git a/arch/powerpc/include/asm/mm-arch-hooks.h b/arch/powerpc/include/asm/mm-arch-hooks.h
index f2a2da8..ea6da89 100644
--- a/arch/powerpc/include/asm/mm-arch-hooks.h
+++ b/arch/powerpc/include/asm/mm-arch-hooks.h
@@ -18,10 +18,10 @@ static inline void arch_remap(struct mm_struct *mm,
 {
 	/*
 	 * mremap() doesn't allow moving multiple vmas so we can limit the
-	 * check to old_start == vdso_base.
+	 * check to old_start == vdso.
 	 */
-	if (old_start == mm->context.vdso_base)
-		mm->context.vdso_base = new_start;
+	if (old_start == mm->context.vdso)
+		mm->context.vdso = new_start;
 }
 #define arch_remap arch_remap
 
diff --git a/arch/powerpc/include/asm/mmu-40x.h b/arch/powerpc/include/asm/mmu-40x.h
index 3491686..e8e57b7 100644
--- a/arch/powerpc/include/asm/mmu-40x.h
+++ b/arch/powerpc/include/asm/mmu-40x.h
@@ -56,7 +56,7 @@
 typedef struct {
 	unsigned int	id;
 	unsigned int	active;
-	unsigned long	vdso_base;
+	unsigned long	vdso;
 } mm_context_t;
 
 #endif /* !__ASSEMBLY__ */
diff --git a/arch/powerpc/include/asm/mmu-44x.h b/arch/powerpc/include/asm/mmu-44x.h
index bf52d70..471891c 100644
--- a/arch/powerpc/include/asm/mmu-44x.h
+++ b/arch/powerpc/include/asm/mmu-44x.h
@@ -107,7 +107,7 @@ extern unsigned int tlb_44x_index;
 typedef struct {
 	unsigned int	id;
 	unsigned int	active;
-	unsigned long	vdso_base;
+	unsigned long	vdso;
 } mm_context_t;
 
 #endif /* !__ASSEMBLY__ */
diff --git a/arch/powerpc/include/asm/mmu-8xx.h b/arch/powerpc/include/asm/mmu-8xx.h
index 0a566f1..9d1f160 100644
--- a/arch/powerpc/include/asm/mmu-8xx.h
+++ b/arch/powerpc/include/asm/mmu-8xx.h
@@ -167,7 +167,7 @@
 typedef struct {
 	unsigned int id;
 	unsigned int active;
-	unsigned long vdso_base;
+	unsigned long vdso;
 } mm_context_t;
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/powerpc/include/asm/mmu-book3e.h b/arch/powerpc/include/asm/mmu-book3e.h
index cd4f04a..0cf1d11 100644
--- a/arch/powerpc/include/asm/mmu-book3e.h
+++ b/arch/powerpc/include/asm/mmu-book3e.h
@@ -228,7 +228,7 @@ extern unsigned int tlbcam_index;
 typedef struct {
 	unsigned int	id;
 	unsigned int	active;
-	unsigned long	vdso_base;
+	unsigned long	vdso;
 #ifdef CONFIG_PPC_MM_SLICES
 	u64 low_slices_psize;   /* SLB page size encodings */
 	u64 high_slices_psize;  /* 4 bits per slice for now */
diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
index 4eaab40..508b842 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -139,8 +139,8 @@ 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;
+	if (start <= mm->context.vdso && mm->context.vdso < end)
+		mm->context.vdso = 0;
 }
 
 static inline void arch_bprm_mm_init(struct mm_struct *mm,
diff --git a/arch/powerpc/include/asm/vdso.h b/arch/powerpc/include/asm/vdso.h
index c53f5f6..fc90971 100644
--- a/arch/powerpc/include/asm/vdso.h
+++ b/arch/powerpc/include/asm/vdso.h
@@ -17,7 +17,7 @@
 
 #ifndef __ASSEMBLY__
 
-/* Offsets relative to thread->vdso_base */
+/* Offsets relative to mm->context.vdso */
 extern unsigned long vdso64_rt_sigtramp;
 extern unsigned long vdso32_sigtramp;
 extern unsigned long vdso32_rt_sigtramp;
diff --git a/arch/powerpc/include/uapi/asm/elf.h b/arch/powerpc/include/uapi/asm/elf.h
index c2d21d1..6cf0bbf 100644
--- a/arch/powerpc/include/uapi/asm/elf.h
+++ b/arch/powerpc/include/uapi/asm/elf.h
@@ -177,7 +177,7 @@ do {									\
 	NEW_AUX_ENT(AT_DCACHEBSIZE, dcache_bsize);			\
 	NEW_AUX_ENT(AT_ICACHEBSIZE, icache_bsize);			\
 	NEW_AUX_ENT(AT_UCACHEBSIZE, ucache_bsize);			\
-	VDSO_AUX_ENT(AT_SYSINFO_EHDR, current->mm->context.vdso_base);	\
+	VDSO_AUX_ENT(AT_SYSINFO_EHDR, current->mm->context.vdso);	\
 } while (0)
 
 /* PowerPC64 relocations defined by the ABIs */
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index b6aa378..39c39d72 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -1000,9 +1000,9 @@ int handle_rt_signal32(struct ksignal *ksig, sigset_t *oldset,
 	/* Save user registers on the stack */
 	frame = &rt_sf->uc.uc_mcontext;
 	addr = frame;
-	if (vdso32_rt_sigtramp && current->mm->context.vdso_base) {
+	if (vdso32_rt_sigtramp && current->mm->context.vdso) {
 		sigret = 0;
-		tramp = current->mm->context.vdso_base + vdso32_rt_sigtramp;
+		tramp = current->mm->context.vdso + vdso32_rt_sigtramp;
 	} else {
 		sigret = __NR_rt_sigreturn;
 		tramp = (unsigned long) frame->tramp;
@@ -1425,9 +1425,9 @@ int handle_signal32(struct ksignal *ksig, sigset_t *oldset, struct pt_regs *regs
 	    || __put_user(ksig->sig, &sc->signal))
 		goto badframe;
 
-	if (vdso32_sigtramp && current->mm->context.vdso_base) {
+	if (vdso32_sigtramp && current->mm->context.vdso) {
 		sigret = 0;
-		tramp = current->mm->context.vdso_base + vdso32_sigtramp;
+		tramp = current->mm->context.vdso + vdso32_sigtramp;
 	} else {
 		sigret = __NR_sigreturn;
 		tramp = (unsigned long) frame->mctx.tramp;
diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index 2552079..4cb437f 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -751,8 +751,8 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set, struct pt_regs *regs
 	current->thread.fp_state.fpscr = 0;
 
 	/* Set up to return from userspace. */
-	if (vdso64_rt_sigtramp && current->mm->context.vdso_base) {
-		regs->link = current->mm->context.vdso_base + vdso64_rt_sigtramp;
+	if (vdso64_rt_sigtramp && current->mm->context.vdso) {
+		regs->link = current->mm->context.vdso + vdso64_rt_sigtramp;
 	} else {
 		err |= setup_trampoline(__NR_rt_sigreturn, &frame->tramp[0]);
 		if (err)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index def1b8b..e6e5f68 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -179,7 +179,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	vdso_base = VDSO32_MBASE;
 #endif
 
-	current->mm->context.vdso_base = 0;
+	current->mm->context.vdso = 0;
 
 	/* vDSO has a problem and was disabled, just don't "enable" it for the
 	 * process
@@ -213,7 +213,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	 * install_special_mapping or the perf counter mmap tracking code
 	 * will fail to recognise it as a vDSO (since arch_vma_name fails).
 	 */
-	current->mm->context.vdso_base = vdso_base;
+	current->mm->context.vdso = vdso_base;
 
 	/*
 	 * our vma flags don't have VM_WRITE so by default, the process isn't
@@ -230,7 +230,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				     vdso_pagelist);
 	if (rc) {
-		current->mm->context.vdso_base = 0;
+		current->mm->context.vdso = 0;
 		goto fail_mmapsem;
 	}
 
@@ -244,7 +244,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 const char *arch_vma_name(struct vm_area_struct *vma)
 {
-	if (vma->vm_mm && vma->vm_start == vma->vm_mm->context.vdso_base)
+	if (vma->vm_mm && vma->vm_start == vma->vm_mm->context.vdso)
 		return "[vdso]";
 	return NULL;
 }
diff --git a/arch/powerpc/perf/callchain.c b/arch/powerpc/perf/callchain.c
index e04a675..04fc505 100644
--- a/arch/powerpc/perf/callchain.c
+++ b/arch/powerpc/perf/callchain.c
@@ -209,8 +209,8 @@ static int is_sigreturn_64_address(unsigned long nip, unsigned long fp)
 {
 	if (nip == fp + offsetof(struct signal_frame_64, tramp))
 		return 1;
-	if (vdso64_rt_sigtramp && current->mm->context.vdso_base &&
-	    nip == current->mm->context.vdso_base + vdso64_rt_sigtramp)
+	if (vdso64_rt_sigtramp && current->mm->context.vdso &&
+	    nip == current->mm->context.vdso + vdso64_rt_sigtramp)
 		return 1;
 	return 0;
 }
@@ -368,8 +368,8 @@ static int is_sigreturn_32_address(unsigned int nip, unsigned int fp)
 {
 	if (nip == fp + offsetof(struct signal_frame_32, mctx.mc_pad))
 		return 1;
-	if (vdso32_sigtramp && current->mm->context.vdso_base &&
-	    nip == current->mm->context.vdso_base + vdso32_sigtramp)
+	if (vdso32_sigtramp && current->mm->context.vdso &&
+	    nip == current->mm->context.vdso + vdso32_sigtramp)
 		return 1;
 	return 0;
 }
@@ -379,8 +379,8 @@ static int is_rt_sigreturn_32_address(unsigned int nip, unsigned int fp)
 	if (nip == fp + offsetof(struct rt_signal_frame_32,
 				 uc.uc_mcontext.mc_pad))
 		return 1;
-	if (vdso32_rt_sigtramp && current->mm->context.vdso_base &&
-	    nip == current->mm->context.vdso_base + vdso32_rt_sigtramp)
+	if (vdso32_rt_sigtramp && current->mm->context.vdso &&
+	    nip == current->mm->context.vdso + vdso32_rt_sigtramp)
 		return 1;
 	return 0;
 }
-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [RFC 2/5] mm/powerpc: Make VDSO unmap generic
  2016-04-28 15:18   ` VDSO unmap and remap support for additional architectures Christopher Covington
  2016-04-28 15:18     ` [RFC 1/5] powerpc: Rename context.vdso_base to context.vdso Christopher Covington
@ 2016-04-28 15:18     ` Christopher Covington
  2016-04-28 15:18     ` [RFC 3/5] mm/powerpc: Make VDSO remap generic Christopher Covington
                       ` (3 subsequent siblings)
  5 siblings, 0 replies; 15+ messages in thread
From: Christopher Covington @ 2016-04-28 15:18 UTC (permalink / raw)
  To: Catalin Marinas, criu, Laurent Dufour, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Arnd Bergmann, linux-arm-kernel, linux-kernel, linuxppc-dev,
	linux-arch, linux-mm
  Cc: Christopher Covington

In order to support unmapping the VDSO on additional architectures, move the
unmap code out from arch/powerpc. Architectures that wish to use the generic
logic must have an unsigned long vdso in mm->context and can opt in by
selecting CONFIG_ARCH_WANT_VDSO_MAP. This allows PowerPC to go back to using
the generic MM hooks, instead of carrying its own.

Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
 arch/powerpc/Kconfig                   |  1 +
 arch/powerpc/include/asm/mmu_context.h | 35 +---------------------------------
 include/asm-generic/mm_hooks.h         |  4 ++++
 3 files changed, 6 insertions(+), 34 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 7cd32c0..f74320e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -160,6 +160,7 @@ config PPC
 	select HAVE_ARCH_SECCOMP_FILTER
 	select ARCH_HAS_UBSAN_SANITIZE_ALL
 	select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
+	select ARCH_WANT_VDSO_MAP
 
 config GENERIC_CSUM
 	def_bool CPU_LITTLE_ENDIAN
diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
index 508b842..3e51842 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,6 +8,7 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
+#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*
@@ -126,39 +127,5 @@ 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 && mm->context.vdso < end)
-		mm->context.vdso = 0;
-}
-
-static inline void arch_bprm_mm_init(struct mm_struct *mm,
-				     struct vm_area_struct *vma)
-{
-}
-
-static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,
-		bool write, bool execute, bool foreign)
-{
-	/* by default, allow everything */
-	return true;
-}
-
-static inline bool arch_pte_access_permitted(pte_t pte, bool write)
-{
-	/* by default, allow everything */
-	return true;
-}
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
diff --git a/include/asm-generic/mm_hooks.h b/include/asm-generic/mm_hooks.h
index cc5d9a14..6645116 100644
--- a/include/asm-generic/mm_hooks.h
+++ b/include/asm-generic/mm_hooks.h
@@ -19,6 +19,10 @@ static inline void arch_unmap(struct mm_struct *mm,
 			struct vm_area_struct *vma,
 			unsigned long start, unsigned long end)
 {
+#ifdef CONFIG_ARCH_WANT_VDSO_MAP
+	if (start <= mm->context.vdso && mm->context.vdso < end)
+		mm->context.vdso = 0;
+#endif  /* CONFIG_ARCH_WANT_VDSO_MAP */
 }
 
 static inline void arch_bprm_mm_init(struct mm_struct *mm,
-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [RFC 3/5] mm/powerpc: Make VDSO remap generic
  2016-04-28 15:18   ` VDSO unmap and remap support for additional architectures Christopher Covington
  2016-04-28 15:18     ` [RFC 1/5] powerpc: Rename context.vdso_base to context.vdso Christopher Covington
  2016-04-28 15:18     ` [RFC 2/5] mm/powerpc: Make VDSO unmap generic Christopher Covington
@ 2016-04-28 15:18     ` Christopher Covington
  2016-04-28 15:18     ` [RFC 4/5] arm64: Use unsigned long for vdso Christopher Covington
                       ` (2 subsequent siblings)
  5 siblings, 0 replies; 15+ messages in thread
From: Christopher Covington @ 2016-04-28 15:18 UTC (permalink / raw)
  To: Catalin Marinas, criu, Laurent Dufour, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Arnd Bergmann, linux-arm-kernel, linux-kernel, linuxppc-dev,
	linux-arch, linux-mm
  Cc: Christopher Covington

In order to support remapping the VDSO on additional architectures without
duplicating code, move the remap code out from arch/powerpc. Architectures
that wish to use the generic logic must have an unsigned long vdso in
mm->context and can opt in by selecting CONFIG_ARCH_WANT_VDSO_MAP. This
allows PowerPC to use mm-arch-hooks.h from include/asm-generic.

Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
 arch/powerpc/include/asm/Kbuild          |  1 +
 arch/powerpc/include/asm/mm-arch-hooks.h | 28 ----------------------------
 mm/mremap.c                              | 10 ++++++++--
 3 files changed, 9 insertions(+), 30 deletions(-)
 delete mode 100644 arch/powerpc/include/asm/mm-arch-hooks.h

diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild
index ab9f4e0..9dbb372 100644
--- a/arch/powerpc/include/asm/Kbuild
+++ b/arch/powerpc/include/asm/Kbuild
@@ -7,3 +7,4 @@ generic-y += mcs_spinlock.h
 generic-y += preempt.h
 generic-y += rwsem.h
 generic-y += vtime.h
+generic-y += mm-arch-hooks.h
diff --git a/arch/powerpc/include/asm/mm-arch-hooks.h b/arch/powerpc/include/asm/mm-arch-hooks.h
deleted file mode 100644
index ea6da89..0000000
--- a/arch/powerpc/include/asm/mm-arch-hooks.h
+++ /dev/null
@@ -1,28 +0,0 @@
-/*
- * Architecture specific mm hooks
- *
- * Copyright (C) 2015, IBM Corporation
- * Author: Laurent Dufour <ldufour@linux.vnet.ibm.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef _ASM_POWERPC_MM_ARCH_HOOKS_H
-#define _ASM_POWERPC_MM_ARCH_HOOKS_H
-
-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.
-	 */
-	if (old_start == mm->context.vdso)
-		mm->context.vdso = new_start;
-}
-#define arch_remap arch_remap
-
-#endif /* _ASM_POWERPC_MM_ARCH_HOOKS_H */
diff --git a/mm/mremap.c b/mm/mremap.c
index 3fa0a467..59032b7 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -293,8 +293,14 @@ static unsigned long move_vma(struct vm_area_struct *vma,
 		old_addr = new_addr;
 		new_addr = err;
 	} else {
-		arch_remap(mm, old_addr, old_addr + old_len,
-			   new_addr, new_addr + new_len);
+#ifdef CONFIG_ARCH_WANT_VDSO_MAP
+		/*
+		 * mremap() doesn't allow moving multiple vmas so we can limit the
+		 * check to old_addr == vdso.
+		 */
+		if (old_addr == mm->context.vdso)
+			mm->context.vdso = new_addr;
+#endif  /* CONFIG_ARCH_WANT_VDSO_MAP */
 	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */
-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [RFC 4/5] arm64: Use unsigned long for vdso
  2016-04-28 15:18   ` VDSO unmap and remap support for additional architectures Christopher Covington
                       ` (2 preceding siblings ...)
  2016-04-28 15:18     ` [RFC 3/5] mm/powerpc: Make VDSO remap generic Christopher Covington
@ 2016-04-28 15:18     ` Christopher Covington
  2016-04-28 15:18     ` [RFC 5/5] arm64: Gain VDSO unmap and remap powers Christopher Covington
  2016-04-28 18:53     ` VDSO unmap and remap support for additional architectures Andy Lutomirski
  5 siblings, 0 replies; 15+ messages in thread
From: Christopher Covington @ 2016-04-28 15:18 UTC (permalink / raw)
  To: Catalin Marinas, criu, Laurent Dufour, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Arnd Bergmann, linux-arm-kernel, linux-kernel, linuxppc-dev,
	linux-arch, linux-mm
  Cc: Christopher Covington

In order to get AArch64 remap and unmap support for the VDSO, like PowerPC
and x86 have, without duplicating the code, we need a common name and type
for the address of the VDSO. An informal survey of the architectures
indicates unsigned long vdso is popular. Change the type in arm64 to be
unsigned long, which has the added benefit of dropping a few typecasts.

Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
 arch/arm64/include/asm/mmu.h | 2 +-
 arch/arm64/kernel/vdso.c     | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index 990124a..a67352f 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -18,7 +18,7 @@
 
 typedef struct {
 	atomic64_t	id;
-	void		*vdso;
+	unsigned long	vdso;
 } mm_context_t;
 
 /*
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 97bc68f..e742b1d 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -96,7 +96,7 @@ int aarch32_setup_vectors_page(struct linux_binprm *bprm, int uses_interp)
 	void *ret;
 
 	down_write(&mm->mmap_sem);
-	current->mm->context.vdso = (void *)addr;
+	current->mm->context.vdso = addr;
 
 	/* Map vectors page at the high address. */
 	ret = _install_special_mapping(mm, addr, PAGE_SIZE,
@@ -176,7 +176,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
 		goto up_fail;
 
 	vdso_base += PAGE_SIZE;
-	mm->context.vdso = (void *)vdso_base;
+	mm->context.vdso = vdso_base;
 	ret = _install_special_mapping(mm, vdso_base, vdso_text_len,
 				       VM_READ|VM_EXEC|
 				       VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
@@ -189,7 +189,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
 	return 0;
 
 up_fail:
-	mm->context.vdso = NULL;
+	mm->context.vdso = 0;
 	up_write(&mm->mmap_sem);
 	return PTR_ERR(ret);
 }
-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [RFC 5/5] arm64: Gain VDSO unmap and remap powers
  2016-04-28 15:18   ` VDSO unmap and remap support for additional architectures Christopher Covington
                       ` (3 preceding siblings ...)
  2016-04-28 15:18     ` [RFC 4/5] arm64: Use unsigned long for vdso Christopher Covington
@ 2016-04-28 15:18     ` Christopher Covington
  2016-04-28 18:53     ` VDSO unmap and remap support for additional architectures Andy Lutomirski
  5 siblings, 0 replies; 15+ messages in thread
From: Christopher Covington @ 2016-04-28 15:18 UTC (permalink / raw)
  To: Catalin Marinas, criu, Laurent Dufour, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Arnd Bergmann, linux-arm-kernel, linux-kernel, linuxppc-dev,
	linux-arch, linux-mm
  Cc: Christopher Covington

Checkpoint/Restore In Userspace (CRIU) must be able to remap and unmap the
Virtual Dynamic Shared Object (VDSO) to be able to handle the changing
addresses that result from address space layout randomization. Now that the
support for this originally written for PowerPC has been moved to a generic
location and arm64 has adopted unsigned long for the type of mm->context.vdso,
simply opt-in to VDSO unmap and remap support.

Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4f43622..cbdce39 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -14,6 +14,7 @@ config ARM64
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
 	select ARCH_WANT_FRAME_POINTERS
+	select ARCH_WANT_VDSO_MAP
 	select ARCH_HAS_UBSAN_SANITIZE_ALL
 	select ARM_AMBA
 	select ARM_ARCH_TIMER
-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: VDSO unmap and remap support for additional architectures
  2016-04-28 15:18   ` VDSO unmap and remap support for additional architectures Christopher Covington
                       ` (4 preceding siblings ...)
  2016-04-28 15:18     ` [RFC 5/5] arm64: Gain VDSO unmap and remap powers Christopher Covington
@ 2016-04-28 18:53     ` Andy Lutomirski
  2016-04-29 13:22       ` Christopher Covington
  5 siblings, 1 reply; 15+ messages in thread
From: Andy Lutomirski @ 2016-04-28 18:53 UTC (permalink / raw)
  To: Christopher Covington, Catalin Marinas, criu, Laurent Dufour,
	Will Deacon, Benjamin Herrenschmidt, Paul Mackerras,
	Michael Ellerman, Arnd Bergmann, linux-arm-kernel, linux-kernel,
	linuxppc-dev, linux-arch, linux-mm, dsafonov

On 04/28/2016 08:18 AM, Christopher Covington wrote:
> Please take a look at the following prototype of sharing the PowerPC
> VDSO unmap and remap code with other architectures. I've only hooked
> up arm64 to begin with. If folks think this is a reasonable approach I
> can work on 32 bit ARM as well. Not hearing back from an earlier
> request for guidance [1], I simply dove in and started hacking.
> Laurent's test case [2][3] is a compelling illustration of whether VDSO
> remap works or not on a given architecture.

I think there's a much nicer way:

https://lkml.kernel.org/r/1461584223-9418-1-git-send-email-dsafonov@virtuozzo.com

Could arm64 and ppc use this approach?  These arch_xyz hooks are gross.

Also, at some point, possibly quite soon, x86 will want a way for user code to ask the kernel to map a specific vdso variant at a specific address.  Could we perhaps add a new pair of syscalls:

struct vdso_info {
    unsigned long space_needed_before;
    unsigned long space_needed_after;
    unsigned long alignment;
};

long vdso_get_info(unsigned int vdso_type, struct vdso_info *info);

long vdso_remap(unsigned int vdso_type, unsigned long addr, unsigned int flags);

#define VDSO_X86_I386 0
#define VDSO_X86_64 1
#define VDSO_X86_X32 2
// etc.

vdso_remap will map the vdso of the chosen type such at AT_SYSINFO_EHDR lines up with addr.  It will use up to space_needed_before bytes before that address and space_needed_after after than address.  It will also unmap the old vdso (or maybe only do that if some flag is set).

On x86, mremap is *not* sufficient for everything that's needed, because some programs will need to change the vdso type.

--Andy

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: VDSO unmap and remap support for additional architectures
  2016-04-28 18:53     ` VDSO unmap and remap support for additional architectures Andy Lutomirski
@ 2016-04-29 13:22       ` Christopher Covington
  2016-04-29 13:55         ` Dmitry Safonov
  0 siblings, 1 reply; 15+ messages in thread
From: Christopher Covington @ 2016-04-29 13:22 UTC (permalink / raw)
  To: Andy Lutomirski, Catalin Marinas, criu, Dmitry Safonov,
	Will Deacon, Benjamin Herrenschmidt, Paul Mackerras,
	Michael Ellerman, Arnd Bergmann, linux-arm-kernel, linux-kernel,
	linuxppc-dev, linux-arch, linux-mm, dsafonov

Hi Andy,

On 04/28/2016 02:53 PM, Andy Lutomirski wrote:
> On 04/28/2016 08:18 AM, Christopher Covington wrote:
>> Please take a look at the following prototype of sharing the PowerPC
>> VDSO unmap and remap code with other architectures. I've only hooked
>> up arm64 to begin with. If folks think this is a reasonable approach I
>> can work on 32 bit ARM as well. Not hearing back from an earlier
>> request for guidance [1], I simply dove in and started hacking.
>> Laurent's test case [2][3] is a compelling illustration of whether VDSO
>> remap works or not on a given architecture.
> 
> I think there's a much nicer way:
> 
> https://lkml.kernel.org/r/1461584223-9418-1-git-send-email-dsafonov@virtuozzo.com
> 
> Could arm64 and ppc use this approach?  These arch_xyz hooks are gross.

Thanks for the pointer. Any thoughts on how to keep essentially
identical definitions of vdso_mremap from proliferating into every
architecture and variant?

> Also, at some point, possibly quite soon, x86 will want a way for
> user code to ask the kernel to map a specific vdso variant at a specific
> address. Could we perhaps add a new pair of syscalls:
> 
> struct vdso_info {
>     unsigned long space_needed_before;
>     unsigned long space_needed_after;
>     unsigned long alignment;
> };
> 
> long vdso_get_info(unsigned int vdso_type, struct vdso_info *info);
> 
> long vdso_remap(unsigned int vdso_type, unsigned long addr, unsigned int flags);
> 
> #define VDSO_X86_I386 0
> #define VDSO_X86_64 1
> #define VDSO_X86_X32 2
> // etc.
> 
> vdso_remap will map the vdso of the chosen type such at
> AT_SYSINFO_EHDR lines up with addr. It will use up to
> space_needed_before bytes before that address and space_needed_after
> after than address. It will also unmap the old vdso (or maybe only do
> that if some flag is set).
> 
> On x86, mremap is *not* sufficient for everything that's needed,
> because some programs will need to change the vdso type.

I don't I understand. Why can't people just exec() the ELF type that
corresponds to the VDSO they want?

Thanks,
Cov

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: VDSO unmap and remap support for additional architectures
  2016-04-29 13:22       ` Christopher Covington
@ 2016-04-29 13:55         ` Dmitry Safonov
  2016-05-03 21:37           ` Christopher Covington
  0 siblings, 1 reply; 15+ messages in thread
From: Dmitry Safonov @ 2016-04-29 13:55 UTC (permalink / raw)
  To: Christopher Covington, Andy Lutomirski, Catalin Marinas, criu,
	Will Deacon, Benjamin Herrenschmidt, Paul Mackerras,
	Michael Ellerman, Arnd Bergmann, linux-arm-kernel, linux-kernel,
	linuxppc-dev, linux-arch, linux-mm

On 04/29/2016 04:22 PM, Christopher Covington wrote:
> On 04/28/2016 02:53 PM, Andy Lutomirski wrote:
>> Also, at some point, possibly quite soon, x86 will want a way for
>> user code to ask the kernel to map a specific vdso variant at a specific
>> address. Could we perhaps add a new pair of syscalls:
>>
>> struct vdso_info {
>>      unsigned long space_needed_before;
>>      unsigned long space_needed_after;
>>      unsigned long alignment;
>> };
>>
>> long vdso_get_info(unsigned int vdso_type, struct vdso_info *info);
>>
>> long vdso_remap(unsigned int vdso_type, unsigned long addr, unsigned int flags);
>>
>> #define VDSO_X86_I386 0
>> #define VDSO_X86_64 1
>> #define VDSO_X86_X32 2
>> // etc.
>>
>> vdso_remap will map the vdso of the chosen type such at
>> AT_SYSINFO_EHDR lines up with addr. It will use up to
>> space_needed_before bytes before that address and space_needed_after
>> after than address. It will also unmap the old vdso (or maybe only do
>> that if some flag is set).
>>
>> On x86, mremap is *not* sufficient for everything that's needed,
>> because some programs will need to change the vdso type.
> I don't I understand. Why can't people just exec() the ELF type that
> corresponds to the VDSO they want?

I may say about my needs in it: to not lose all the existing
information in application.
Imagine you're restoring a container with 64-bit and 32-bit
applications (in compatible mode). So you need somehow
switch vdso type in restorer for a 32-bit application.
Yes, you may exec() and then - all already restored application
properties will got lost. You will need to transpher information
about mappings, make protocol between restorer binary
and main criu application, finally you'll end up with some
really much more difficult architecture than it is now.
And it'll be slower.

Also it's pretty logical: if one can switch between modes,
why can't he change vdso mapping to mode he got to?
(note: if the work about removing thread compatible flags
will be done (on x86), there will not even be such a thing,
as application mode - just difference on which syscalls it
uses: compatible or native).

Thanks,
     Dmitry Safonov

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC 1/5] powerpc: Rename context.vdso_base to context.vdso
  2016-04-28 15:18     ` [RFC 1/5] powerpc: Rename context.vdso_base to context.vdso Christopher Covington
@ 2016-05-02  1:05       ` Balbir Singh
  2016-05-04 21:21         ` Christopher Covington
  0 siblings, 1 reply; 15+ messages in thread
From: Balbir Singh @ 2016-05-02  1:05 UTC (permalink / raw)
  To: Christopher Covington, Catalin Marinas, criu, Laurent Dufour,
	Will Deacon, Benjamin Herrenschmidt, Paul Mackerras,
	Michael Ellerman, Arnd Bergmann, linux-arm-kernel, linux-kernel,
	linuxppc-dev, linux-arch, linux-mm



On 29/04/16 01:18, Christopher Covington wrote:
> In order to share remap and unmap support for the VDSO with other
> architectures without duplicating the code, we need a common name and type
> for the address of the VDSO. An informal survey of the architectures
> indicates unsigned long vdso is popular. Change the variable name in
> powerpc from mm->context.vdso_base to simply mm->context.vdso.
> 

Could you please provide additional details on why the remap/unmap operations are required?
This patch does rename, but should it abstract via a function acesss to vmap field using arch_* operations? Not sure

Balbir Singh

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: VDSO unmap and remap support for additional architectures
  2016-04-29 13:55         ` Dmitry Safonov
@ 2016-05-03 21:37           ` Christopher Covington
  0 siblings, 0 replies; 15+ messages in thread
From: Christopher Covington @ 2016-05-03 21:37 UTC (permalink / raw)
  To: Dmitry Safonov, Andy Lutomirski, Catalin Marinas, criu,
	Will Deacon, Benjamin Herrenschmidt, Paul Mackerras,
	Michael Ellerman, Arnd Bergmann, linux-arm-kernel, linux-kernel,
	linuxppc-dev, linux-arch, linux-mm, CRIU

On 04/29/2016 09:55 AM, Dmitry Safonov wrote:
> On 04/29/2016 04:22 PM, Christopher Covington wrote:
>> On 04/28/2016 02:53 PM, Andy Lutomirski wrote:
>>> Also, at some point, possibly quite soon, x86 will want a way for
>>> user code to ask the kernel to map a specific vdso variant at a specific
>>> address. Could we perhaps add a new pair of syscalls:
>>>
>>> struct vdso_info {
>>>      unsigned long space_needed_before;
>>>      unsigned long space_needed_after;
>>>      unsigned long alignment;
>>> };
>>>
>>> long vdso_get_info(unsigned int vdso_type, struct vdso_info *info);
>>>
>>> long vdso_remap(unsigned int vdso_type, unsigned long addr, unsigned
>>> int flags);
>>>
>>> #define VDSO_X86_I386 0
>>> #define VDSO_X86_64 1
>>> #define VDSO_X86_X32 2
>>> // etc.
>>>
>>> vdso_remap will map the vdso of the chosen type such at
>>> AT_SYSINFO_EHDR lines up with addr. It will use up to
>>> space_needed_before bytes before that address and space_needed_after
>>> after than address. It will also unmap the old vdso (or maybe only do
>>> that if some flag is set).
>>>
>>> On x86, mremap is *not* sufficient for everything that's needed,
>>> because some programs will need to change the vdso type.
>> I don't I understand. Why can't people just exec() the ELF type that
>> corresponds to the VDSO they want?
> 
> I may say about my needs in it: to not lose all the existing
> information in application.
> Imagine you're restoring a container with 64-bit and 32-bit
> applications (in compatible mode). So you need somehow
> switch vdso type in restorer for a 32-bit application.
> Yes, you may exec() and then - all already restored application
> properties will got lost. You will need to transpher information
> about mappings, make protocol between restorer binary
> and main criu application, finally you'll end up with some
> really much more difficult architecture than it is now.
> And it'll be slower.

Perhaps a more modest exec based strategy would be for x86_64 criu to
handle all of the x86_64 restores as usual but exec i386 and/or x32 criu
service daemons and use them for restoring applications needing those ABIs.

Regards,
Christopher Covington

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC 1/5] powerpc: Rename context.vdso_base to context.vdso
  2016-05-02  1:05       ` Balbir Singh
@ 2016-05-04 21:21         ` Christopher Covington
  0 siblings, 0 replies; 15+ messages in thread
From: Christopher Covington @ 2016-05-04 21:21 UTC (permalink / raw)
  To: Balbir Singh, Catalin Marinas, criu, Laurent Dufour, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Arnd Bergmann, linux-arm-kernel, linux-kernel, linuxppc-dev,
	linux-arch, linux-mm

Hi Balbir,

On 05/01/2016 09:05 PM, Balbir Singh wrote:
> On 29/04/16 01:18, Christopher Covington wrote:
>> In order to share remap and unmap support for the VDSO with other
>> architectures without duplicating the code, we need a common name and type
>> for the address of the VDSO. An informal survey of the architectures
>> indicates unsigned long vdso is popular. Change the variable name in
>> powerpc from mm->context.vdso_base to simply mm->context.vdso.
> 
> Could you please provide additional details on why the remap/unmap operations are required?

The goal is to make checkpointing and restoring processes work on
several different architectures and ABIs, in the face of Address Space
Layout Randomization (ASLR) and other factors that might change the VDSO
virtual address from one exec() to the next.

Here's the patch adding PowerPC support:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=83d3f0e90c6c8f833e3da91917c243a916fda69e

> This patch does rename, but should it abstract via a function acesss
> to vmap field using arch_* operations? Not sure

I'm sorry, but I don't understand this question. Are you saying ARM,
Power etc. need VDSO unmap and remap log that behave differently? So far
I've found the differences to be stylistic rather than really affecting
generated code behavior.

Thanks,
Christopher Covington

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2016-05-04 21:21 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-25 12:49 [PATCH] arm64: Support VDSO remapping Christopher Covington
2015-12-02 12:19 ` Will Deacon
2015-12-03 18:05   ` Christopher Covington
2016-04-28 15:18   ` VDSO unmap and remap support for additional architectures Christopher Covington
2016-04-28 15:18     ` [RFC 1/5] powerpc: Rename context.vdso_base to context.vdso Christopher Covington
2016-05-02  1:05       ` Balbir Singh
2016-05-04 21:21         ` Christopher Covington
2016-04-28 15:18     ` [RFC 2/5] mm/powerpc: Make VDSO unmap generic Christopher Covington
2016-04-28 15:18     ` [RFC 3/5] mm/powerpc: Make VDSO remap generic Christopher Covington
2016-04-28 15:18     ` [RFC 4/5] arm64: Use unsigned long for vdso Christopher Covington
2016-04-28 15:18     ` [RFC 5/5] arm64: Gain VDSO unmap and remap powers Christopher Covington
2016-04-28 18:53     ` VDSO unmap and remap support for additional architectures Andy Lutomirski
2016-04-29 13:22       ` Christopher Covington
2016-04-29 13:55         ` Dmitry Safonov
2016-05-03 21:37           ` Christopher Covington

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).