From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by kanga.kvack.org (Postfix) with ESMTP id 4FC046B0038 for ; Fri, 20 Mar 2015 11:53:39 -0400 (EDT) Received: by wixw10 with SMTP id w10so24653934wix.0 for ; Fri, 20 Mar 2015 08:53:38 -0700 (PDT) Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com. [195.75.94.110]) by mx.google.com with ESMTPS id h6si3781331wix.3.2015.03.20.08.53.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Mar 2015 08:53:37 -0700 (PDT) Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 20 Mar 2015 15:53:36 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id C53E3219004D for ; Fri, 20 Mar 2015 15:53:22 +0000 (GMT) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2KFrXa38585490 for ; Fri, 20 Mar 2015 15:53:33 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2KFrVst005488 for ; Fri, 20 Mar 2015 09:53:32 -0600 From: Laurent Dufour Subject: [PATCH 0/2] Tracking user space vDSO remaping Date: Fri, 20 Mar 2015 16:53:26 +0100 Message-Id: Sender: owner-linux-mm@kvack.org List-ID: To: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by kanga.kvack.org (Postfix) with ESMTP id 639206B006C for ; Fri, 20 Mar 2015 11:53:41 -0400 (EDT) Received: by wggv3 with SMTP id v3so92929451wgg.1 for ; Fri, 20 Mar 2015 08:53:40 -0700 (PDT) Received: from e06smtp16.uk.ibm.com (e06smtp16.uk.ibm.com. [195.75.94.112]) by mx.google.com with ESMTPS id dk4si3731820wib.95.2015.03.20.08.53.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Mar 2015 08:53:39 -0700 (PDT) Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 20 Mar 2015 15:53:38 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 37CA8219005F for ; Fri, 20 Mar 2015 15:53:26 +0000 (GMT) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2KFraXH7668124 for ; Fri, 20 Mar 2015 15:53:36 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2KFrXBC005569 for ; Fri, 20 Mar 2015 09:53:36 -0600 From: Laurent Dufour Subject: [PATCH 1/2] mm: Introducing arch_remap hook Date: Fri, 20 Mar 2015 16:53:27 +0100 Message-Id: <503499aae380db1c4673f146bcba6ad095021257.1426866405.git.ldufour@linux.vnet.ibm.com> In-Reply-To: References: In-Reply-To: References: Sender: owner-linux-mm@kvack.org List-ID: To: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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 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 --- 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 #include +#include #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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by kanga.kvack.org (Postfix) with ESMTP id 697686B006E for ; Fri, 20 Mar 2015 11:53:45 -0400 (EDT) Received: by wgra20 with SMTP id a20so92818088wgr.3 for ; Fri, 20 Mar 2015 08:53:44 -0700 (PDT) Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com. [195.75.94.111]) by mx.google.com with ESMTPS id us7si7574870wjc.151.2015.03.20.08.53.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Mar 2015 08:53:44 -0700 (PDT) Received: from /spool/local by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 20 Mar 2015 15:53:42 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 4357417D805A for ; Fri, 20 Mar 2015 15:54:05 +0000 (GMT) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2KFrdYh3801428 for ; Fri, 20 Mar 2015 15:53:39 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2KFratt005657 for ; Fri, 20 Mar 2015 09:53:38 -0600 From: Laurent Dufour Subject: [PATCH 2/2] powerpc/mm: Tracking vDSO remap Date: Fri, 20 Mar 2015 16:53:28 +0100 Message-Id: <462eda8901babf0a08b5ef642684ae1c6303bd5b.1426866405.git.ldufour@linux.vnet.ibm.com> In-Reply-To: References: In-Reply-To: References: Sender: owner-linux-mm@kvack.org List-ID: To: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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 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 --- 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 #include #include -#include #include /* @@ -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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by kanga.kvack.org (Postfix) with ESMTP id 1501F6B0038 for ; Fri, 20 Mar 2015 19:19:49 -0400 (EDT) Received: by wibg7 with SMTP id g7so539432wib.1 for ; Fri, 20 Mar 2015 16:19:48 -0700 (PDT) Received: from radon.swed.at (a.ns.miles-group.at. [95.130.255.143]) by mx.google.com with ESMTPS id hq9si9068479wjb.91.2015.03.20.16.19.46 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 20 Mar 2015 16:19:47 -0700 (PDT) Message-ID: <550CAB0A.8070402@nod.at> Date: Sat, 21 Mar 2015 00:19:38 +0100 From: Richard Weinberger MIME-Version: 1.0 Subject: Re: [PATCH 1/2] mm: Introducing arch_remap hook References: <503499aae380db1c4673f146bcba6ad095021257.1426866405.git.ldufour@linux.vnet.ibm.com> In-Reply-To: <503499aae380db1c4673f146bcba6ad095021257.1426866405.git.ldufour@linux.vnet.ibm.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Laurent Dufour , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by kanga.kvack.org (Postfix) with ESMTP id 1E5E86B0072 for ; Mon, 23 Mar 2015 04:52:15 -0400 (EDT) Received: by wixw10 with SMTP id w10so55214373wix.0 for ; Mon, 23 Mar 2015 01:52:14 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com. [2a00:1450:400c:c03::22c]) by mx.google.com with ESMTPS id lf5si182004wjb.111.2015.03.23.01.52.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 01:52:13 -0700 (PDT) Received: by wegp1 with SMTP id p1so131768666weg.1 for ; Mon, 23 Mar 2015 01:52:12 -0700 (PDT) Date: Mon, 23 Mar 2015 09:52:09 +0100 From: Ingo Molnar Subject: Re: [PATCH 1/2] mm: Introducing arch_remap hook Message-ID: <20150323085209.GA28965@gmail.com> References: <503499aae380db1c4673f146bcba6ad095021257.1426866405.git.ldufour@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <503499aae380db1c4673f146bcba6ad095021257.1426866405.git.ldufour@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Laurent Dufour Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org * Laurent Dufour wrote: > Some architecture would like to be triggered when a memory area is moved > through the mremap system call. > > This patch is introducing a new arch_remap mm hook which is placed in the > path of mremap, and is called before the old area is unmapped (and the > arch_unmap hook is called). > > 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 > --- > 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by kanga.kvack.org (Postfix) with ESMTP id 5F10D6B0074 for ; Mon, 23 Mar 2015 05:11:30 -0400 (EDT) Received: by wibg7 with SMTP id g7so41448256wib.1 for ; Mon, 23 Mar 2015 02:11:29 -0700 (PDT) Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com. [195.75.94.110]) by mx.google.com with ESMTPS id h3si10711017wix.93.2015.03.23.02.11.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Mar 2015 02:11:28 -0700 (PDT) Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 23 Mar 2015 09:11:27 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 2934717D805F for ; Mon, 23 Mar 2015 09:11:53 +0000 (GMT) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2N9BQck53805080 for ; Mon, 23 Mar 2015 09:11:26 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2N9BMHJ011313 for ; Mon, 23 Mar 2015 03:11:25 -0600 Message-ID: <550FD8B6.305@linux.vnet.ibm.com> Date: Mon, 23 Mar 2015 10:11:18 +0100 From: Laurent Dufour MIME-Version: 1.0 Subject: Re: [PATCH 1/2] mm: Introducing arch_remap hook References: <503499aae380db1c4673f146bcba6ad095021257.1426866405.git.ldufour@linux.vnet.ibm.com> <20150323085209.GA28965@gmail.com> In-Reply-To: <20150323085209.GA28965@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org On 23/03/2015 09:52, Ingo Molnar wrote: > > * Laurent Dufour wrote: > >> Some architecture would like to be triggered when a memory area is moved >> through the mremap system call. >> >> This patch is introducing a new arch_remap mm hook which is placed in the >> path of mremap, and is called before the old area is unmapped (and the >> arch_unmap hook is called). >> >> 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 >> --- >> 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by kanga.kvack.org (Postfix) with ESMTP id 4A2C16B006C for ; Wed, 25 Mar 2015 07:06:47 -0400 (EDT) Received: by wgbcc7 with SMTP id cc7so23038138wgb.0 for ; Wed, 25 Mar 2015 04:06:46 -0700 (PDT) Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com. [195.75.94.108]) by mx.google.com with ESMTPS id u15si3740453wjr.155.2015.03.25.04.06.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 04:06:44 -0700 (PDT) Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Mar 2015 11:06:43 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 4176D1B08069 for ; Wed, 25 Mar 2015 11:07:08 +0000 (GMT) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2PB6gDg11993440 for ; Wed, 25 Mar 2015 11:06:42 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2PB6deN021500 for ; Wed, 25 Mar 2015 05:06:41 -0600 From: Laurent Dufour Subject: [PATCH v2 0/2] Tracking user space vDSO remaping Date: Wed, 25 Mar 2015 12:06:34 +0100 Message-Id: In-Reply-To: <20150323085209.GA28965@gmail.com> References: <20150323085209.GA28965@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by kanga.kvack.org (Postfix) with ESMTP id 295006B006C for ; Wed, 25 Mar 2015 07:06:52 -0400 (EDT) Received: by wixw10 with SMTP id w10so33151482wix.0 for ; Wed, 25 Mar 2015 04:06:51 -0700 (PDT) Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com. [195.75.94.111]) by mx.google.com with ESMTPS id je4si22027957wic.42.2015.03.25.04.06.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 04:06:50 -0700 (PDT) Received: from /spool/local by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Mar 2015 11:06:49 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 901751B08076 for ; Wed, 25 Mar 2015 11:07:12 +0000 (GMT) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2PB6kGU3801448 for ; Wed, 25 Mar 2015 11:06:46 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2PB6hww021664 for ; Wed, 25 Mar 2015 05:06:46 -0600 From: Laurent Dufour Subject: [PATCH v2 1/2] mm: Introducing arch_remap hook Date: Wed, 25 Mar 2015 12:06:35 +0100 Message-Id: In-Reply-To: References: In-Reply-To: References: <20150323085209.GA28965@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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 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 --- 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 #include +#include #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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by kanga.kvack.org (Postfix) with ESMTP id C581A6B006E for ; Wed, 25 Mar 2015 07:06:53 -0400 (EDT) Received: by wixw10 with SMTP id w10so33152601wix.0 for ; Wed, 25 Mar 2015 04:06:53 -0700 (PDT) Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com. [195.75.94.111]) by mx.google.com with ESMTPS id k3si3754322wjr.135.2015.03.25.04.06.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 04:06:52 -0700 (PDT) Received: from /spool/local by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Mar 2015 11:06:51 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id DAC7D1B08070 for ; Wed, 25 Mar 2015 11:07:14 +0000 (GMT) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2PB6m5I8585672 for ; Wed, 25 Mar 2015 11:06:48 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2PB6kI6021809 for ; Wed, 25 Mar 2015 05:06:48 -0600 From: Laurent Dufour Subject: [PATCH v2 2/2] powerpc/mm: Tracking vDSO remap Date: Wed, 25 Mar 2015 12:06:36 +0100 Message-Id: <25152b76585716dc635945c3455ab9b49e645f6d.1427280806.git.ldufour@linux.vnet.ibm.com> In-Reply-To: References: In-Reply-To: References: <20150323085209.GA28965@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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 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 --- 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 #include #include -#include #include /* @@ -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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by kanga.kvack.org (Postfix) with ESMTP id 0B9F36B0038 for ; Wed, 25 Mar 2015 08:11:26 -0400 (EDT) Received: by wgdm6 with SMTP id m6so24965326wgd.2 for ; Wed, 25 Mar 2015 05:11:25 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com. [2a00:1450:400c:c05::232]) by mx.google.com with ESMTPS id fx9si4793584wib.15.2015.03.25.05.11.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 05:11:24 -0700 (PDT) Received: by wibg7 with SMTP id g7so72886075wib.1 for ; Wed, 25 Mar 2015 05:11:23 -0700 (PDT) Date: Wed, 25 Mar 2015 13:11:19 +0100 From: Ingo Molnar Subject: Re: [PATCH v2 2/2] powerpc/mm: Tracking vDSO remap Message-ID: <20150325121118.GA2542@gmail.com> References: <20150323085209.GA28965@gmail.com> <25152b76585716dc635945c3455ab9b49e645f6d.1427280806.git.ldufour@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25152b76585716dc635945c3455ab9b49e645f6d.1427280806.git.ldufour@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Laurent Dufour Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org * Laurent Dufour 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 > --- > 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 > #include > #include > -#include > #include > > /* > @@ -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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by kanga.kvack.org (Postfix) with ESMTP id 5A02D6B0038 for ; Wed, 25 Mar 2015 09:25:28 -0400 (EDT) Received: by wgs2 with SMTP id 2so27394591wgs.1 for ; Wed, 25 Mar 2015 06:25:27 -0700 (PDT) Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com. [195.75.94.109]) by mx.google.com with ESMTPS id bi1si22077015wib.106.2015.03.25.06.25.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 06:25:26 -0700 (PDT) Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Mar 2015 13:25:25 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 5BB851B0805F for ; Wed, 25 Mar 2015 13:25:47 +0000 (GMT) Received: from d06av12.portsmouth.uk.ibm.com (d06av12.portsmouth.uk.ibm.com [9.149.37.247]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2PDPLKt65601784 for ; Wed, 25 Mar 2015 13:25:21 GMT Received: from d06av12.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av12.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2PDPI7B004627 for ; Wed, 25 Mar 2015 07:25:20 -0600 Message-ID: <5512B73C.5050509@linux.vnet.ibm.com> Date: Wed, 25 Mar 2015 14:25:16 +0100 From: Laurent Dufour MIME-Version: 1.0 Subject: Re: [PATCH v2 2/2] powerpc/mm: Tracking vDSO remap References: <20150323085209.GA28965@gmail.com> <25152b76585716dc635945c3455ab9b49e645f6d.1427280806.git.ldufour@linux.vnet.ibm.com> <20150325121118.GA2542@gmail.com> In-Reply-To: <20150325121118.GA2542@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org On 25/03/2015 13:11, Ingo Molnar wrote: > > * Laurent Dufour 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 >> --- >> 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 >> #include >> #include >> -#include >> #include >> >> /* >> @@ -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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by kanga.kvack.org (Postfix) with ESMTP id 0F4FB6B0038 for ; Wed, 25 Mar 2015 09:54:03 -0400 (EDT) Received: by wibgn9 with SMTP id gn9so39900909wib.1 for ; Wed, 25 Mar 2015 06:54:02 -0700 (PDT) Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com. [195.75.94.107]) by mx.google.com with ESMTPS id n9si5168507wie.84.2015.03.25.06.54.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 06:54:01 -0700 (PDT) Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Mar 2015 13:54:00 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 18B422190046 for ; Wed, 25 Mar 2015 13:53:47 +0000 (GMT) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2PDrw092687466 for ; Wed, 25 Mar 2015 13:53:58 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2PDrtN1002858 for ; Wed, 25 Mar 2015 07:53:57 -0600 From: Laurent Dufour Subject: [PATCH v3 0/2] Tracking user space vDSO remaping Date: Wed, 25 Mar 2015 14:53:50 +0100 Message-Id: In-Reply-To: <20150325121118.GA2542@gmail.com> References: <20150325121118.GA2542@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by kanga.kvack.org (Postfix) with ESMTP id E81706B006C for ; Wed, 25 Mar 2015 09:54:06 -0400 (EDT) Received: by wixw10 with SMTP id w10so75100922wix.0 for ; Wed, 25 Mar 2015 06:54:06 -0700 (PDT) Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com. [195.75.94.107]) by mx.google.com with ESMTPS id gp8si22754156wib.20.2015.03.25.06.54.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 06:54:05 -0700 (PDT) Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Mar 2015 13:54:04 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 5BE781B08072 for ; Wed, 25 Mar 2015 13:54:28 +0000 (GMT) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2PDs2EV11731262 for ; Wed, 25 Mar 2015 13:54:02 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2PDrwGd002997 for ; Wed, 25 Mar 2015 07:54:01 -0600 From: Laurent Dufour Subject: [PATCH v3 1/2] mm: Introducing arch_remap hook Date: Wed, 25 Mar 2015 14:53:51 +0100 Message-Id: In-Reply-To: References: In-Reply-To: References: <20150325121118.GA2542@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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 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 --- 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 #include +#include #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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by kanga.kvack.org (Postfix) with ESMTP id 109C46B006E for ; Wed, 25 Mar 2015 09:54:10 -0400 (EDT) Received: by wixw10 with SMTP id w10so75102134wix.0 for ; Wed, 25 Mar 2015 06:54:09 -0700 (PDT) Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com. [195.75.94.107]) by mx.google.com with ESMTPS id gt6si5219807wib.23.2015.03.25.06.54.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 06:54:08 -0700 (PDT) Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Mar 2015 13:54:07 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 4004E17D8056 for ; Wed, 25 Mar 2015 13:54:33 +0000 (GMT) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2PDs5h166650168 for ; Wed, 25 Mar 2015 13:54:05 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2PDs2Gk003182 for ; Wed, 25 Mar 2015 07:54:05 -0600 From: Laurent Dufour Subject: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap Date: Wed, 25 Mar 2015 14:53:52 +0100 Message-Id: In-Reply-To: References: In-Reply-To: References: <20150325121118.GA2542@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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 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 --- 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 #include #include -#include #include /* @@ -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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by kanga.kvack.org (Postfix) with ESMTP id 924906B0032 for ; Wed, 25 Mar 2015 14:33:23 -0400 (EDT) Received: by wgra20 with SMTP id a20so37648658wgr.3 for ; Wed, 25 Mar 2015 11:33:23 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com. [2a00:1450:400c:c00::234]) by mx.google.com with ESMTPS id ey12si6417211wid.87.2015.03.25.11.33.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 11:33:21 -0700 (PDT) Received: by wgdm6 with SMTP id m6so37930987wgd.2 for ; Wed, 25 Mar 2015 11:33:21 -0700 (PDT) Date: Wed, 25 Mar 2015 19:33:16 +0100 From: Ingo Molnar Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap Message-ID: <20150325183316.GA9090@gmail.com> References: <20150325121118.GA2542@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Laurent Dufour Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org * Laurent Dufour 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by kanga.kvack.org (Postfix) with ESMTP id A03156B0032 for ; Wed, 25 Mar 2015 14:36:53 -0400 (EDT) Received: by wibg7 with SMTP id g7so120384612wib.1 for ; Wed, 25 Mar 2015 11:36:53 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com. [2a00:1450:400c:c05::232]) by mx.google.com with ESMTPS id p8si5757906wjx.82.2015.03.25.11.36.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 11:36:52 -0700 (PDT) Received: by wixw10 with SMTP id w10so81036556wix.0 for ; Wed, 25 Mar 2015 11:36:51 -0700 (PDT) Date: Wed, 25 Mar 2015 19:36:47 +0100 From: Ingo Molnar Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap Message-ID: <20150325183647.GA9331@gmail.com> References: <20150325121118.GA2542@gmail.com> <20150325183316.GA9090@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150325183316.GA9090@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Laurent Dufour Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org * Ingo Molnar 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by kanga.kvack.org (Postfix) with ESMTP id D15206B0032 for ; Wed, 25 Mar 2015 17:10:59 -0400 (EDT) Received: by iecvj10 with SMTP id vj10so32514793iec.0 for ; Wed, 25 Mar 2015 14:10:59 -0700 (PDT) Received: from gate.crashing.org (gate.crashing.org. [63.228.1.57]) by mx.google.com with ESMTPS id mv7si3307504igb.14.2015.03.25.14.10.58 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Mar 2015 14:10:59 -0700 (PDT) Message-ID: <1427317797.6468.86.camel@kernel.crashing.org> Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap From: Benjamin Herrenschmidt Date: Thu, 26 Mar 2015 08:09:57 +1100 In-Reply-To: <20150325183316.GA9090@gmail.com> References: <20150325121118.GA2542@gmail.com> <20150325183316.GA9090@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Laurent Dufour , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org On Wed, 2015-03-25 at 19:33 +0100, Ingo Molnar wrote: > * Laurent Dufour 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) by kanga.kvack.org (Postfix) with ESMTP id 654366B006C for ; Wed, 25 Mar 2015 17:16:56 -0400 (EDT) Received: by igcau2 with SMTP id au2so113194853igc.0 for ; Wed, 25 Mar 2015 14:16:56 -0700 (PDT) Received: from gate.crashing.org (gate.crashing.org. [63.228.1.57]) by mx.google.com with ESMTPS id d197si2947433ioe.54.2015.03.25.14.16.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Mar 2015 14:16:55 -0700 (PDT) Message-ID: <1427317867.6468.87.camel@kernel.crashing.org> Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap From: Benjamin Herrenschmidt Date: Thu, 26 Mar 2015 08:11:07 +1100 In-Reply-To: <20150325183647.GA9331@gmail.com> References: <20150325121118.GA2542@gmail.com> <20150325183316.GA9090@gmail.com> <20150325183647.GA9331@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Laurent Dufour , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote: > * Ingo Molnar 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by kanga.kvack.org (Postfix) with ESMTP id 0861F6B0032 for ; Thu, 26 Mar 2015 05:43:37 -0400 (EDT) Received: by wgdm6 with SMTP id m6so57727884wgd.2 for ; Thu, 26 Mar 2015 02:43:36 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com. [2a00:1450:400c:c05::22e]) by mx.google.com with ESMTPS id u15si8968621wjr.155.2015.03.26.02.43.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 02:43:35 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so76776033wib.1 for ; Thu, 26 Mar 2015 02:43:34 -0700 (PDT) Date: Thu, 26 Mar 2015 10:43:30 +0100 From: Ingo Molnar Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap Message-ID: <20150326094330.GA15407@gmail.com> References: <20150325121118.GA2542@gmail.com> <20150325183316.GA9090@gmail.com> <20150325183647.GA9331@gmail.com> <1427317867.6468.87.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1427317867.6468.87.camel@kernel.crashing.org> Sender: owner-linux-mm@kvack.org List-ID: To: Benjamin Herrenschmidt Cc: Laurent Dufour , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org * Benjamin Herrenschmidt wrote: > On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote: > > * Ingo Molnar 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by kanga.kvack.org (Postfix) with ESMTP id 55C0C6B0032 for ; Thu, 26 Mar 2015 05:48:50 -0400 (EDT) Received: by wgs2 with SMTP id 2so57933662wgs.1 for ; Thu, 26 Mar 2015 02:48:49 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com. [2a00:1450:400c:c05::22c]) by mx.google.com with ESMTPS id qa2si27308343wic.10.2015.03.26.02.48.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 02:48:49 -0700 (PDT) Received: by wiaa2 with SMTP id a2so14270462wia.0 for ; Thu, 26 Mar 2015 02:48:48 -0700 (PDT) Date: Thu, 26 Mar 2015 10:48:44 +0100 From: Ingo Molnar Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap Message-ID: <20150326094844.GB15407@gmail.com> References: <20150325121118.GA2542@gmail.com> <20150325183316.GA9090@gmail.com> <1427317797.6468.86.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1427317797.6468.86.camel@kernel.crashing.org> Sender: owner-linux-mm@kvack.org List-ID: To: Benjamin Herrenschmidt Cc: Laurent Dufour , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org * Benjamin Herrenschmidt 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by kanga.kvack.org (Postfix) with ESMTP id 12D7A6B0032 for ; Thu, 26 Mar 2015 06:14:03 -0400 (EDT) Received: by wibg7 with SMTP id g7so142334529wib.1 for ; Thu, 26 Mar 2015 03:14:02 -0700 (PDT) Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com. [195.75.94.108]) by mx.google.com with ESMTPS id gy8si9784215wib.118.2015.03.26.03.14.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Mar 2015 03:14:01 -0700 (PDT) Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Mar 2015 10:14:00 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 84D8D1B08069 for ; Thu, 26 Mar 2015 10:14:24 +0000 (GMT) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2QADwfv64880858 for ; Thu, 26 Mar 2015 10:13:58 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2QADtxE024090 for ; Thu, 26 Mar 2015 04:13:57 -0600 Message-ID: <5513DBE1.4070404@linux.vnet.ibm.com> Date: Thu, 26 Mar 2015 11:13:53 +0100 From: Laurent Dufour MIME-Version: 1.0 Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap References: <20150325121118.GA2542@gmail.com> <20150325183316.GA9090@gmail.com> <1427317797.6468.86.camel@kernel.crashing.org> <20150326094844.GB15407@gmail.com> In-Reply-To: <20150326094844.GB15407@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar , Benjamin Herrenschmidt Cc: Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org On 26/03/2015 10:48, Ingo Molnar wrote: > > * Benjamin Herrenschmidt 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by kanga.kvack.org (Postfix) with ESMTP id 8E5626B0032 for ; Thu, 26 Mar 2015 06:37:44 -0400 (EDT) Received: by wgra20 with SMTP id a20so58960408wgr.3 for ; Thu, 26 Mar 2015 03:37:44 -0700 (PDT) Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com. [195.75.94.111]) by mx.google.com with ESMTPS id je4si27473136wic.42.2015.03.26.03.37.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Mar 2015 03:37:43 -0700 (PDT) Received: from /spool/local by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Mar 2015 10:37:42 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 4493317D805A for ; Thu, 26 Mar 2015 10:38:07 +0000 (GMT) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2QAbcR47995806 for ; Thu, 26 Mar 2015 10:37:38 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2QAbZE5027874 for ; Thu, 26 Mar 2015 04:37:38 -0600 Message-ID: <5513E16D.1030101@linux.vnet.ibm.com> Date: Thu, 26 Mar 2015 11:37:33 +0100 From: Laurent Dufour MIME-Version: 1.0 Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap References: <20150325121118.GA2542@gmail.com> <20150325183316.GA9090@gmail.com> <20150325183647.GA9331@gmail.com> <1427317867.6468.87.camel@kernel.crashing.org> <20150326094330.GA15407@gmail.com> In-Reply-To: <20150326094330.GA15407@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar , Benjamin Herrenschmidt Cc: Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org On 26/03/2015 10:43, Ingo Molnar wrote: > > * Benjamin Herrenschmidt wrote: > >> On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote: >>> * Ingo Molnar 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by kanga.kvack.org (Postfix) with ESMTP id 48B096B006C for ; Thu, 26 Mar 2015 10:17:41 -0400 (EDT) Received: by wgs2 with SMTP id 2so66084321wgs.1 for ; Thu, 26 Mar 2015 07:17:40 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com. [2a00:1450:400c:c05::230]) by mx.google.com with ESMTPS id gz6si10115750wjc.142.2015.03.26.07.17.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 07:17:39 -0700 (PDT) Received: by wibg7 with SMTP id g7so150310998wib.1 for ; Thu, 26 Mar 2015 07:17:39 -0700 (PDT) Date: Thu, 26 Mar 2015 15:17:31 +0100 From: Ingo Molnar Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap Message-ID: <20150326141730.GA23060@gmail.com> References: <20150325121118.GA2542@gmail.com> <20150325183316.GA9090@gmail.com> <20150325183647.GA9331@gmail.com> <1427317867.6468.87.camel@kernel.crashing.org> <20150326094330.GA15407@gmail.com> <5513E16D.1030101@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5513E16D.1030101@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Laurent Dufour Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org * Laurent Dufour 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by kanga.kvack.org (Postfix) with ESMTP id 692256B0070 for ; Thu, 26 Mar 2015 10:32:41 -0400 (EDT) Received: by wgbcc7 with SMTP id cc7so65808987wgb.0 for ; Thu, 26 Mar 2015 07:32:40 -0700 (PDT) Received: from e06smtp17.uk.ibm.com (e06smtp17.uk.ibm.com. [195.75.94.113]) by mx.google.com with ESMTPS id r4si28448697wix.67.2015.03.26.07.32.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Mar 2015 07:32:39 -0700 (PDT) Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Mar 2015 14:32:37 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id C44DB17D810A for ; Thu, 26 Mar 2015 14:32:37 +0000 (GMT) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2QEW9Qd1704388 for ; Thu, 26 Mar 2015 14:32:09 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2QEW7Pm011521 for ; Thu, 26 Mar 2015 08:32:09 -0600 Message-ID: <55141866.6080007@linux.vnet.ibm.com> Date: Thu, 26 Mar 2015 15:32:06 +0100 From: Laurent Dufour MIME-Version: 1.0 Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap References: <20150325121118.GA2542@gmail.com> <20150325183316.GA9090@gmail.com> <20150325183647.GA9331@gmail.com> <1427317867.6468.87.camel@kernel.crashing.org> <20150326094330.GA15407@gmail.com> <5513E16D.1030101@linux.vnet.ibm.com> <20150326141730.GA23060@gmail.com> In-Reply-To: <20150326141730.GA23060@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org On 26/03/2015 15:17, Ingo Molnar wrote: > > * Laurent Dufour 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by kanga.kvack.org (Postfix) with ESMTP id EE9FD6B0032 for ; Thu, 26 Mar 2015 13:38:02 -0400 (EDT) Received: by wibbg6 with SMTP id bg6so73495792wib.0 for ; Thu, 26 Mar 2015 10:38:02 -0700 (PDT) Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com. [195.75.94.111]) by mx.google.com with ESMTPS id ln14si11798782wic.10.2015.03.26.10.38.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Mar 2015 10:38:01 -0700 (PDT) Received: from /spool/local by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Mar 2015 17:38:00 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 8669B17D8056 for ; Thu, 26 Mar 2015 17:38:23 +0000 (GMT) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2QHbtbJ3866896 for ; Thu, 26 Mar 2015 17:37:55 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2QHbsbU032124 for ; Thu, 26 Mar 2015 11:37:55 -0600 From: Laurent Dufour Subject: [PATCH v4 0/2] Tracking user space vDSO remaping Date: Thu, 26 Mar 2015 18:37:51 +0100 Message-Id: In-Reply-To: <20150326141730.GA23060@gmail.com> References: <20150326141730.GA23060@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by kanga.kvack.org (Postfix) with ESMTP id 8AE686B006C for ; Thu, 26 Mar 2015 13:38:04 -0400 (EDT) Received: by wiaa2 with SMTP id a2so33010268wia.0 for ; Thu, 26 Mar 2015 10:38:04 -0700 (PDT) Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com. [195.75.94.107]) by mx.google.com with ESMTPS id eh6si4355634wib.92.2015.03.26.10.38.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Mar 2015 10:38:02 -0700 (PDT) Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Mar 2015 17:38:01 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 4F50217D8062 for ; Thu, 26 Mar 2015 17:38:24 +0000 (GMT) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2QHbtI48061410 for ; Thu, 26 Mar 2015 17:37:56 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2QHbt36032151 for ; Thu, 26 Mar 2015 11:37:55 -0600 From: Laurent Dufour Subject: [PATCH v4 1/2] mm: Introducing arch_remap hook Date: Thu, 26 Mar 2015 18:37:52 +0100 Message-Id: In-Reply-To: References: In-Reply-To: References: <20150326141730.GA23060@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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 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 --- 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 #include +#include #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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by kanga.kvack.org (Postfix) with ESMTP id DB3486B006E for ; Thu, 26 Mar 2015 13:38:06 -0400 (EDT) Received: by wgdm6 with SMTP id m6so72714383wgd.2 for ; Thu, 26 Mar 2015 10:38:06 -0700 (PDT) Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com. [195.75.94.111]) by mx.google.com with ESMTPS id hn10si29287307wib.81.2015.03.26.10.38.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Mar 2015 10:38:02 -0700 (PDT) Received: from /spool/local by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Mar 2015 17:38:01 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 6B8711B0807A for ; Thu, 26 Mar 2015 17:38:23 +0000 (GMT) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2QHbuQA7405992 for ; Thu, 26 Mar 2015 17:37:56 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2QHbtG1032188 for ; Thu, 26 Mar 2015 11:37:56 -0600 From: Laurent Dufour Subject: [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap Date: Thu, 26 Mar 2015 18:37:53 +0100 Message-Id: <7fdae652993cf88bdd633d65e5a8f81c7ad8a1e3.1427390952.git.ldufour@linux.vnet.ibm.com> In-Reply-To: References: In-Reply-To: References: <20150326141730.GA23060@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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 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 --- 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 #include #include -#include #include /* @@ -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<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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by kanga.kvack.org (Postfix) with ESMTP id EB8B76B006C for ; Thu, 26 Mar 2015 14:55:56 -0400 (EDT) Received: by wibg7 with SMTP id g7so23256968wib.1 for ; Thu, 26 Mar 2015 11:55:56 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com. [2a00:1450:400c:c00::22b]) by mx.google.com with ESMTPS id co6si11387208wjb.54.2015.03.26.11.55.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 11:55:55 -0700 (PDT) Received: by wgbcc7 with SMTP id cc7so74015418wgb.0 for ; Thu, 26 Mar 2015 11:55:55 -0700 (PDT) Date: Thu, 26 Mar 2015 19:55:50 +0100 From: Ingo Molnar Subject: Re: [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap Message-ID: <20150326185550.GA25547@gmail.com> References: <20150326141730.GA23060@gmail.com> <7fdae652993cf88bdd633d65e5a8f81c7ad8a1e3.1427390952.git.ldufour@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7fdae652993cf88bdd633d65e5a8f81c7ad8a1e3.1427390952.git.ldufour@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Laurent Dufour Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org * Laurent Dufour 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< + > + /* 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 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) by kanga.kvack.org (Postfix) with ESMTP id 12DD46B006C for ; Thu, 26 Mar 2015 19:23:55 -0400 (EDT) Received: by igcau2 with SMTP id au2so22367202igc.1 for ; Thu, 26 Mar 2015 16:23:54 -0700 (PDT) Received: from gate.crashing.org (gate.crashing.org. [63.228.1.57]) by mx.google.com with ESMTPS id n14si2658657igx.1.2015.03.26.16.23.54 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Mar 2015 16:23:54 -0700 (PDT) Message-ID: <1427412183.6468.148.camel@kernel.crashing.org> Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap From: Benjamin Herrenschmidt Date: Fri, 27 Mar 2015 10:23:03 +1100 In-Reply-To: <20150326094330.GA15407@gmail.com> References: <20150325121118.GA2542@gmail.com> <20150325183316.GA9090@gmail.com> <20150325183647.GA9331@gmail.com> <1427317867.6468.87.camel@kernel.crashing.org> <20150326094330.GA15407@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Laurent Dufour , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org On Thu, 2015-03-26 at 10:43 +0100, Ingo Molnar wrote: > * Benjamin Herrenschmidt wrote: > > > On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote: > > > * Ingo Molnar 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by kanga.kvack.org (Postfix) with ESMTP id 001766B0032 for ; Fri, 27 Mar 2015 07:02:24 -0400 (EDT) Received: by wgra20 with SMTP id a20so94889529wgr.3 for ; Fri, 27 Mar 2015 04:02:24 -0700 (PDT) Received: from e06smtp17.uk.ibm.com (e06smtp17.uk.ibm.com. [195.75.94.113]) by mx.google.com with ESMTPS id lf5si2666108wjb.111.2015.03.27.04.02.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Mar 2015 04:02:23 -0700 (PDT) Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 27 Mar 2015 11:02:21 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 18615219005C for ; Fri, 27 Mar 2015 11:02:06 +0000 (GMT) Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2RB2HLC59310332 for ; Fri, 27 Mar 2015 11:02:17 GMT Received: from d06av11.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2RB2Gj0007685 for ; Fri, 27 Mar 2015 05:02:17 -0600 Message-ID: <551538B5.2030507@linux.vnet.ibm.com> Date: Fri, 27 Mar 2015 12:02:13 +0100 From: Laurent Dufour MIME-Version: 1.0 Subject: Re: [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap References: <20150326141730.GA23060@gmail.com> <7fdae652993cf88bdd633d65e5a8f81c7ad8a1e3.1427390952.git.ldufour@linux.vnet.ibm.com> <20150326185550.GA25547@gmail.com> In-Reply-To: <20150326185550.GA25547@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, cov@codeaurora.org, criu@openvz.org On 26/03/2015 19:55, Ingo Molnar wrote: > > * Laurent Dufour 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<> + >> + /* 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 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by kanga.kvack.org (Postfix) with ESMTP id 7F4656B0255 for ; Wed, 2 Mar 2016 07:13:16 -0500 (EST) Received: by mail-pa0-f53.google.com with SMTP id fy10so131782122pac.1 for ; Wed, 02 Mar 2016 04:13:16 -0800 (PST) Received: from smtp.codeaurora.org (smtp.codeaurora.org. [198.145.29.96]) by mx.google.com with ESMTPS id qy17si6007395pac.171.2016.03.02.04.13.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Mar 2016 04:13:15 -0800 (PST) Subject: Re: [PATCH 0/2] Tracking user space vDSO remaping References: From: Christopher Covington Message-ID: <56D6D8D6.6060306@codeaurora.org> Date: Wed, 2 Mar 2016 07:13:10 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Laurent Dufour Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Arnd Bergmann , 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, criu@openvz.org, "linux-arm-kernel@lists.infradead.org" , Will Deacon , Laura Abbott , David Brown 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: email@kvack.org