From: Laurent Dufour <ldufour@linux.vnet.ibm.com> To: Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, Michael Ellerman <mpe@ellerman.id.au>, Jeff Dike <jdike@addtoit.com>, Richard Weinberger <richard@nod.at>, Guan Xuetao <gxt@mprc.pku.edu.cn>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org, Arnd Bergmann <arnd@arndb.de>, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, user-mode-linux-user@lists.sourceforge.net, linux-arch@vger.kernel.org, linux-mm@kvack.org Cc: cov@codeaurora.org, criu@openvz.org Subject: [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap Date: Thu, 26 Mar 2015 18:37:53 +0100 [thread overview] Message-ID: <7fdae652993cf88bdd633d65e5a8f81c7ad8a1e3.1427390952.git.ldufour@linux.vnet.ibm.com> (raw) In-Reply-To: <cover.1427390952.git.ldufour@linux.vnet.ibm.com> In-Reply-To: <cover.1427390952.git.ldufour@linux.vnet.ibm.com> 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>
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Dufour <ldufour@linux.vnet.ibm.com> To: Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, Michael Ellerman <mpe@ellerman.id.au>, Jeff Dike <jdike@addtoit.com>, Richard Weinberger <richard@nod.at>, Guan Xuetao <gxt@mprc.pku.edu.cn>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org, Arnd Bergmann <arnd@arndb.de>, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, user-mode-linux-user@lists.sourceforge.net, linux-arch@vger.kernel.org, linux-mm@kvack.org Cc: cov@codeaurora.org, criu@openvz.org Subject: [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap Date: Thu, 26 Mar 2015 18:37:53 +0100 [thread overview] Message-ID: <7fdae652993cf88bdd633d65e5a8f81c7ad8a1e3.1427390952.git.ldufour@linux.vnet.ibm.com> (raw) Message-ID: <20150326173753.H3lQocgq1CVd9I0T53YqBniJ7-yWuqdwHvh9tyCddrY@z> (raw) In-Reply-To: <cover.1427390952.git.ldufour@linux.vnet.ibm.com> In-Reply-To: <cover.1427390952.git.ldufour@linux.vnet.ibm.com> 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
next prev parent reply other threads:[~2015-03-26 17:37 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-03-20 15:53 [PATCH 0/2] Tracking user space vDSO remaping Laurent Dufour 2015-03-20 15:53 ` Laurent Dufour 2015-03-20 15:53 ` [PATCH 1/2] mm: Introducing arch_remap hook Laurent Dufour 2015-03-20 15:53 ` Laurent Dufour 2015-03-20 23:19 ` Richard Weinberger 2015-03-20 23:19 ` Richard Weinberger 2015-03-23 8:52 ` Ingo Molnar 2015-03-23 9:11 ` Laurent Dufour 2015-03-23 9:11 ` Laurent Dufour 2015-03-25 11:06 ` [PATCH v2 0/2] Tracking user space vDSO remaping Laurent Dufour 2015-03-25 11:06 ` Laurent Dufour 2015-03-25 11:06 ` [PATCH v2 1/2] mm: Introducing arch_remap hook Laurent Dufour 2015-03-25 11:06 ` Laurent Dufour 2015-03-25 11:06 ` [PATCH v2 2/2] powerpc/mm: Tracking vDSO remap Laurent Dufour 2015-03-25 11:06 ` Laurent Dufour 2015-03-25 12:11 ` Ingo Molnar 2015-03-25 12:11 ` Ingo Molnar 2015-03-25 13:25 ` Laurent Dufour 2015-03-25 13:25 ` Laurent Dufour 2015-03-25 13:53 ` [PATCH v3 0/2] Tracking user space vDSO remaping Laurent Dufour 2015-03-25 13:53 ` Laurent Dufour 2015-03-25 13:53 ` [PATCH v3 1/2] mm: Introducing arch_remap hook Laurent Dufour 2015-03-25 13:53 ` [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap Laurent Dufour 2015-03-25 13:53 ` Laurent Dufour 2015-03-25 18:33 ` Ingo Molnar 2015-03-25 18:36 ` Ingo Molnar 2015-03-25 21:11 ` Benjamin Herrenschmidt 2015-03-25 21:11 ` Benjamin Herrenschmidt 2015-03-26 9:43 ` Ingo Molnar 2015-03-26 9:43 ` Ingo Molnar 2015-03-26 10:37 ` Laurent Dufour 2015-03-26 10:37 ` Laurent Dufour 2015-03-26 14:17 ` Ingo Molnar 2015-03-26 14:32 ` Laurent Dufour 2015-03-26 14:32 ` Laurent Dufour 2015-03-26 17:37 ` [PATCH v4 0/2] Tracking user space vDSO remaping Laurent Dufour 2015-03-26 17:37 ` Laurent Dufour 2015-03-26 17:37 ` [PATCH v4 1/2] mm: Introducing arch_remap hook Laurent Dufour 2015-03-26 17:37 ` Laurent Dufour 2015-03-26 17:37 ` Laurent Dufour [this message] 2015-03-26 17:37 ` [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap Laurent Dufour 2015-03-26 18:55 ` Ingo Molnar 2015-03-26 18:55 ` Ingo Molnar 2015-03-27 11:02 ` Laurent Dufour 2015-03-26 23:23 ` [PATCH v3 " Benjamin Herrenschmidt 2015-03-26 23:23 ` Benjamin Herrenschmidt 2015-03-25 21:09 ` Benjamin Herrenschmidt 2015-03-25 21:09 ` Benjamin Herrenschmidt 2015-03-26 9:48 ` Ingo Molnar 2015-03-26 9:48 ` Ingo Molnar 2015-03-26 10:13 ` Laurent Dufour 2015-03-20 15:53 ` [PATCH " Laurent Dufour 2015-03-20 15:53 ` Laurent Dufour 2016-03-02 12:13 ` [PATCH 0/2] Tracking user space vDSO remaping Christopher Covington 2016-03-02 12:13 ` Christopher Covington
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=7fdae652993cf88bdd633d65e5a8f81c7ad8a1e3.1427390952.git.ldufour@linux.vnet.ibm.com \ --to=ldufour@linux.vnet.ibm.com \ --cc=arnd@arndb.de \ --cc=benh@kernel.crashing.org \ --cc=cov@codeaurora.org \ --cc=criu@openvz.org \ --cc=gxt@mprc.pku.edu.cn \ --cc=hpa@zytor.com \ --cc=jdike@addtoit.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-s390@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mingo@redhat.com \ --cc=mpe@ellerman.id.au \ --cc=paulus@samba.org \ --cc=richard@nod.at \ --cc=tglx@linutronix.de \ --cc=user-mode-linux-devel@lists.sourceforge.net \ --cc=user-mode-linux-user@lists.sourceforge.net \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).