From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1fq5-0006q9-Ef for qemu-devel@nongnu.org; Wed, 06 May 2009 08:03:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1fq1-0006pK-8S for qemu-devel@nongnu.org; Wed, 06 May 2009 08:03:02 -0400 Received: from [199.232.76.173] (port=59300 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1fpz-0006oq-A9 for qemu-devel@nongnu.org; Wed, 06 May 2009 08:02:59 -0400 Received: from naru.obs2.net ([84.20.150.76]:51611) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M1fpy-0003Z9-FS for qemu-devel@nongnu.org; Wed, 06 May 2009 08:02:58 -0400 Date: Wed, 6 May 2009 15:02:56 +0300 From: Riku Voipio Subject: Re: [Qemu-devel] [PATCH] linux-user: implement pipe2 syscall Message-ID: <20090506120256.GA21149@kos.to> References: <20090505133048.GA29646@kos.to> <20090505225809.GJ7574@shareable.org> <20090506080023.GA7230@kos.to> <20090506110832.GC23364@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090506110832.GC23364@shareable.org> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org On Wed, May 06, 2009 at 12:08:32PM +0100, Jamie Lokier wrote: > But it's not a bug to call execve(), or fork() then execve(), in > another thread at the same time as descriptors are being created. > Those calls scan the whole file descriptor table, and look at the > FD_CLOEXEC flags. Now this discussion would be much more useful if qemu was actually properly threadsafe to begin with... > I haven't looked too closely at how guest file descriptors are handled > in QEMU these days. In an older version I'm looking at, guest file > descriptors are simply host file descriptors so the pipe2 emulation is > broken in this way. > If QEMU maintained a guest file descriptor table internally, emulating > what a kernel does, this would be solved automatically, but it doesn't. > You can solve it quite simply for any host kernel with the lock > solution I just posted in another mail on this thread. The same > method works for all the other syscalls taking *_CLOEXEC flags, so > it's probably a good idea :-) Either of these suggested changes are separate new features, and would thus need to be implemented as separate patches. Thanks for patches in advance :-)