From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752596AbbCZKhv (ORCPT ); Thu, 26 Mar 2015 06:37:51 -0400 Received: from e06smtp11.uk.ibm.com ([195.75.94.107]:58160 "EHLO e06smtp11.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751533AbbCZKhs (ORCPT ); Thu, 26 Mar 2015 06:37:48 -0400 Message-ID: <5513E16D.1030101@linux.vnet.ibm.com> Date: Thu, 26 Mar 2015 11:37:33 +0100 From: Laurent Dufour User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 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 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 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15032610-0041-0000-0000-000003DC240F Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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...