From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Dufour Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap Date: Thu, 26 Mar 2015 11:13:53 +0100 Message-ID: <5513DBE1.4070404@linux.vnet.ibm.com> References: <20150325121118.GA2542@gmail.com> <20150325183316.GA9090@gmail.com> <1427317797.6468.86.camel@kernel.crashing.org> <20150326094844.GB15407@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: Received: from e06smtp16.uk.ibm.com ([195.75.94.112]:53386 "EHLO e06smtp16.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751552AbbCZKOG (ORCPT ); Thu, 26 Mar 2015 06:14:06 -0400 Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Mar 2015 10:14:05 -0000 In-Reply-To: <20150326094844.GB15407@gmail.com> Sender: linux-arch-owner@vger.kernel.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.