From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap Date: Fri, 27 Mar 2015 10:23:03 +1100 Message-ID: <1427412183.6468.148.camel@kernel.crashing.org> References: <20150325121118.GA2542@gmail.com> <20150325183316.GA9090@gmail.com> <20150325183647.GA9331@gmail.com> <1427317867.6468.87.camel@kernel.crashing.org> <20150326094330.GA15407@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150326094330.GA15407@gmail.com> Sender: owner-linux-mm@kvack.org 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 List-Id: linux-arch.vger.kernel.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 gate.crashing.org ([63.228.1.57]:59729 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752101AbbC0AGE (ORCPT ); Thu, 26 Mar 2015 20:06:04 -0400 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: linux-arch-owner@vger.kernel.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 Message-ID: <20150326232303.XYEFCHQtNz1FUf33nfKxJtUN9_Jb0Y_imb5EDjknMmI@z> 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <1427412183.6468.148.camel@kernel.crashing.org> 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> Mime-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: linuxppc-dev-bounces+geert=linux-m68k.org@lists.ozlabs.org Sender: "Linuxppc-dev" Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap To: Ingo Molnar Cc: linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, Laurent Dufour , user-mode-linux-devel@lists.sourceforge.net, Arnd Bergmann , Jeff Dike , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, criu@openvz.org, linux-mm@kvack.org, Ingo Molnar , Paul Mackerras , cov@codeaurora.org, user-mode-linux-user@lists.sourceforge.net, Richard Weinberger , Thomas Gleixner , Guan Xuetao , linuxppc-dev@lists.ozlabs.org List-ID: T24gVGh1LCAyMDE1LTAzLTI2IGF0IDEwOjQzICswMTAwLCBJbmdvIE1vbG5hciB3cm90ZToKPiAq IEJlbmphbWluIEhlcnJlbnNjaG1pZHQgPGJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZz4gd3JvdGU6 Cj4gCj4gPiBPbiBXZWQsIDIwMTUtMDMtMjUgYXQgMTk6MzYgKzAxMDAsIEluZ28gTW9sbmFyIHdy b3RlOgo+ID4gPiAqIEluZ28gTW9sbmFyIDxtaW5nb0BrZXJuZWwub3JnPiB3cm90ZToKPiA+ID4g Cj4gPiA+ID4gPiArI2RlZmluZSBfX0hBVkVfQVJDSF9SRU1BUAo+ID4gPiA+ID4gK3N0YXRpYyBp bmxpbmUgdm9pZCBhcmNoX3JlbWFwKHN0cnVjdCBtbV9zdHJ1Y3QgKm1tLAo+ID4gPiA+ID4gKwkJ CSAgICAgIHVuc2lnbmVkIGxvbmcgb2xkX3N0YXJ0LCB1bnNpZ25lZCBsb25nIG9sZF9lbmQsCj4g PiA+ID4gPiArCQkJICAgICAgdW5zaWduZWQgbG9uZyBuZXdfc3RhcnQsIHVuc2lnbmVkIGxvbmcg bmV3X2VuZCkKPiA+ID4gPiA+ICt7Cj4gPiA+ID4gPiArCS8qCj4gPiA+ID4gPiArCSAqIG1yZW1h cCgpIGRvZXNuJ3QgYWxsb3cgbW92aW5nIG11bHRpcGxlIHZtYXMgc28gd2UgY2FuIGxpbWl0IHRo ZQo+ID4gPiA+ID4gKwkgKiBjaGVjayB0byBvbGRfc3RhcnQgPT0gdmRzb19iYXNlLgo+ID4gPiA+ ID4gKwkgKi8KPiA+ID4gPiA+ICsJaWYgKG9sZF9zdGFydCA9PSBtbS0+Y29udGV4dC52ZHNvX2Jh c2UpCj4gPiA+ID4gPiArCQltbS0+Y29udGV4dC52ZHNvX2Jhc2UgPSBuZXdfc3RhcnQ7Cj4gPiA+ ID4gPiArfQo+ID4gPiA+IAo+ID4gPiA+IG1yZW1hcCgpIGRvZXNuJ3QgYWxsb3cgbW92aW5nIG11 bHRpcGxlIHZtYXMsIGJ1dCBpdCBhbGxvd3MgdGhlIAo+ID4gPiA+IG1vdmVtZW50IG9mIG11bHRp LXBhZ2Ugdm1hcyBhbmQgaXQgYWxzbyBhbGxvd3MgcGFydGlhbCBtcmVtYXAoKXMsIAo+ID4gPiA+ IHdoZXJlIGl0IHdpbGwgc3BsaXQgdXAgYSB2bWEuCj4gPiA+IAo+ID4gPiBJLmUuIG1yZW1hcCgp IHN1cHBvcnRzIHRoZSBzaHJpbmtpbmcgKGFuZCBncm93aW5nKSBvZiB2bWFzLiBJbiB0aGF0IAo+ ID4gPiBjYXNlIG1yZW1hcCgpIHdpbGwgdW5tYXAgdGhlIGVuZCBvZiB0aGUgdm1hIGFuZCB3aWxs IHNocmluayB0aGUgCj4gPiA+IHJlbWFpbmluZyB2RFNPIHZtYS4KPiA+ID4gCj4gPiA+IERvZXNu J3QgdGhhdCByZXN1bHQgaW4gYSBub24td29ya2luZyB2RFNPIHRoYXQgc2hvdWxkIHplcm8gb3V0 IAo+ID4gPiB2ZHNvX2Jhc2U/Cj4gPiAKPiA+IFJpZ2h0LiBOb3cgd2UgY2FuJ3QgY29tcGxldGVs eSBwcmV2ZW50IHRoZSB1c2VyIGZyb20gc2hvb3RpbmcgaXRzZWxmIAo+ID4gaW4gdGhlIGZvb3Qg SSBzdXBwb3NlLCB0aG91Z2ggdGhlcmUgaXMgYSBsZWdpdCB1c2FnZSBzY2VuYXJpbyB3aGljaCAK PiA+IGlzIHRvIG1vdmUgdGhlIHZEU08gYXJvdW5kIHdoaWNoIGl0IHdvdWxkIGJlIG5pY2UgdG8g c3VwcG9ydC4gSSAKPiA+IHRoaW5rIGl0J3MgcmVhc29uYWJsZSB0byBwdXQgdGhlIG9udXMgb24g dGhlIHVzZXIgaGVyZSB0byBkbyB0aGUgCj4gPiByaWdodCB0aGluZy4KPiAKPiBJIGFyZ3VlIHdl IHNob3VsZCB1c2UgdGhlIHJpZ2h0IGNvbmRpdGlvbiB0byBjbGVhciB2ZHNvX2Jhc2U6IGlmIHRo ZSAKPiB2RFNPIGdldHMgYXQgbGVhc3QgcGFydGlhbGx5IHVubWFwcGVkLiBPdGhlcndpc2UgdGhl cmUncyBsaXR0bGUgcG9pbnQgCj4gaW4gdGhlIHdob2xlIHBhdGNoOiBlaXRoZXIgY29ycmVjdGx5 IHRyYWNrIHdoZXRoZXIgdGhlIHZEU08gaXMgT0ssIG9yIAo+IGRvbid0IC4uLgoKV2VsbCwgaWYg d2UgYXJlIGdvaW5nIHRvIGNsZWFyIGl0IGF0IGFsbCB5ZXMsIHdlIHNob3VsZCBwcm9iYWJseSBi ZSBhCmJpdCBzbWFydGVyIGFib3V0IGl0LiBNeSBwb2ludCBob3dldmVyIHdhcyB3ZSBwcm9iYWJs eSBkb24ndCBuZWVkIHRvIGJlCnN1cGVyIHJvYnVzdCBhYm91dCBkZWFsaW5nIHdpdGggYW55IGNy YXp5IHNjZW5hcmlvIHVzZXJzcGFjZSBtaWdodApjb25jZWl2ZS4KCj4gVGhlcmUncyBhbHNvIHRo ZSBxdWVzdGlvbiBvZiBtcHJvdGVjdCgpOiBjYW4gdXNlcnMgbXByb3RlY3QoKSB0aGUgdkRTTyAK PiBvbiBQb3dlclBDPwoKTm90aGluZyBwcmV2ZW50cyBpdC4gQnV0IGhlcmUgdG9vLCBJIHdvdWxk bid0IGJvdGhlci4gVGhlIHVzZXIgbWlnaHQgYmUKZG9pbmcgb24gcHVycG9zZSBleHBlY3Rpbmcg dG8gY2F0Y2ggdGhlIHJlc3VsdGluZyBzaWduYWwgZm9yIGV4YW1wbGUKKHRob3VnaCBhcmd1YWJs eSBhIHNpZ25hbCBmcm9tIGEgc2lncmV0dXJuIGZyYW1lIGlzIC4uLiBvZGQpLgoKQ2hlZXJzLApC ZW4uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpMaW51 eHBwYy1kZXYgbWFpbGluZyBsaXN0CkxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnCmh0dHBz Oi8vbGlzdHMub3psYWJzLm9yZy9saXN0aW5mby9saW51eHBwYy1kZXY= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 5E6361A04A3 for ; Fri, 27 Mar 2015 10:42:14 +1100 (AEDT) Message-ID: <1427412183.6468.148.camel@kernel.crashing.org> Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap From: Benjamin Herrenschmidt To: Ingo Molnar 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 Cc: linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, Laurent Dufour , user-mode-linux-devel@lists.sourceforge.net, Arnd Bergmann , Jeff Dike , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, criu@openvz.org, linux-mm@kvack.org, Ingo Molnar , Paul Mackerras , cov@codeaurora.org, user-mode-linux-user@lists.sourceforge.net, Richard Weinberger , Thomas Gleixner , Guan Xuetao , linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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.