From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755492Ab1HWQ62 (ORCPT ); Tue, 23 Aug 2011 12:58:28 -0400 Received: from a.ns.miles-group.at ([95.130.255.143]:47683 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751259Ab1HWQ6X (ORCPT ); Tue, 23 Aug 2011 12:58:23 -0400 Message-ID: <4E53DC2A.3020004@nod.at> Date: Tue, 23 Aug 2011 18:58:18 +0200 From: Richard Weinberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Al Viro CC: Linus Torvalds , Borislav Petkov , Andrew Lutomirski , "H. Peter Anvin" , Ingo Molnar , "user-mode-linux-devel@lists.sourceforge.net" , "linux-kernel@vger.kernel.org" , "mingo@redhat.com" Subject: Re: [uml-devel] SYSCALL, ptrace and syscall restart breakages (Re: [RFC] weird crap with vdso on uml/i386) References: <4E52EF2A.8060608@zytor.com> <20110823010146.GY2203@ZenIV.linux.org.uk> <20110823011312.GZ2203@ZenIV.linux.org.uk> <20110823021717.GA2203@ZenIV.linux.org.uk> <20110823061531.GC2203@ZenIV.linux.org.uk> <20110823162251.GC13138@aftab> <20110823165320.GG2203@ZenIV.linux.org.uk> In-Reply-To: <20110823165320.GG2203@ZenIV.linux.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 23.08.2011 18:53, schrieb Al Viro: > On Tue, Aug 23, 2011 at 09:29:29AM -0700, Linus Torvalds wrote: > >> Oh yes. >> >> System call performance is *important*. And x86 is *important*. >> >> UML? In comparison, not that important. >> >> So quite frankly, if this is purely an UML issue (and unless we're >> missing something else, that's what it looks like, despite all the >> confusion we've had so far), then if we have a choice between "remove >> syscall instruction" and "remove UML", then ... > > Agreed. Note, BTW, that UML has perfectly usable workaround for 99% of > that - don't tell the binaries it has *any* vdso in such cases. And > "remove UML" turns into "remove support under UML for 32bit binaries > that go out of their way to do SYSCALL directly, which wouldn't work > on native 32bit", which is really a no-brainer. What about this hack/solution? While booting UML can check whether the host's vDSO contains a SYSCALL instruction. If so, UML will not make the host's vDSO available to it's processes... Thanks, //richard From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QvuJ4-0007I3-2p for user-mode-linux-devel@lists.sourceforge.net; Tue, 23 Aug 2011 16:58:30 +0000 Received: from a.ns.miles-group.at ([95.130.255.143] helo=radon.swed.at) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1QvuJ2-0005pA-RL for user-mode-linux-devel@lists.sourceforge.net; Tue, 23 Aug 2011 16:58:30 +0000 Message-ID: <4E53DC2A.3020004@nod.at> Date: Tue, 23 Aug 2011 18:58:18 +0200 From: Richard Weinberger MIME-Version: 1.0 References: <4E52EF2A.8060608@zytor.com> <20110823010146.GY2203@ZenIV.linux.org.uk> <20110823011312.GZ2203@ZenIV.linux.org.uk> <20110823021717.GA2203@ZenIV.linux.org.uk> <20110823061531.GC2203@ZenIV.linux.org.uk> <20110823162251.GC13138@aftab> <20110823165320.GG2203@ZenIV.linux.org.uk> In-Reply-To: <20110823165320.GG2203@ZenIV.linux.org.uk> List-Id: The user-mode Linux development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: user-mode-linux-devel-bounces@lists.sourceforge.net Subject: Re: [uml-devel] SYSCALL, ptrace and syscall restart breakages (Re: [RFC] weird crap with vdso on uml/i386) To: Al Viro Cc: Andrew Lutomirski , "user-mode-linux-devel@lists.sourceforge.net" , "linux-kernel@vger.kernel.org" , Borislav Petkov , "mingo@redhat.com" , "H. Peter Anvin" , Linus Torvalds , Ingo Molnar Am 23.08.2011 18:53, schrieb Al Viro: > On Tue, Aug 23, 2011 at 09:29:29AM -0700, Linus Torvalds wrote: > >> Oh yes. >> >> System call performance is *important*. And x86 is *important*. >> >> UML? In comparison, not that important. >> >> So quite frankly, if this is purely an UML issue (and unless we're >> missing something else, that's what it looks like, despite all the >> confusion we've had so far), then if we have a choice between "remove >> syscall instruction" and "remove UML", then ... > > Agreed. Note, BTW, that UML has perfectly usable workaround for 99% of > that - don't tell the binaries it has *any* vdso in such cases. And > "remove UML" turns into "remove support under UML for 32bit binaries > that go out of their way to do SYSCALL directly, which wouldn't work > on native 32bit", which is really a no-brainer. What about this hack/solution? While booting UML can check whether the host's vDSO contains a SYSCALL instruction. If so, UML will not make the host's vDSO available to it's processes... Thanks, //richard ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel