From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap Date: Thu, 26 Mar 2015 15:17:31 +0100 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 Return-path: Received: from mail-wi0-f170.google.com ([209.85.212.170]:33888 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752490AbbCZORk (ORCPT ); Thu, 26 Mar 2015 10:17:40 -0400 Content-Disposition: inline In-Reply-To: <5513E16D.1030101@linux.vnet.ibm.com> Sender: linux-arch-owner@vger.kernel.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