From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1gWD-0000c8-N2 for qemu-devel@nongnu.org; Wed, 06 May 2009 08:46:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1gWD-0000bv-3l for qemu-devel@nongnu.org; Wed, 06 May 2009 08:46:37 -0400 Received: from [199.232.76.173] (port=56907 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1gWC-0000bp-Ut for qemu-devel@nongnu.org; Wed, 06 May 2009 08:46:36 -0400 Received: from dd21438.kasserver.com ([85.13.141.110]:48794) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M1gWC-0003RL-J9 for qemu-devel@nongnu.org; Wed, 06 May 2009 08:46:36 -0400 Message-ID: <4A0186A9.3080902@opensuse.org> Date: Wed, 06 May 2009 14:46:33 +0200 From: Martin Mohring MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] linux-user: implement pipe2 syscall References: <20090505133048.GA29646@kos.to> <20090505225809.GJ7574@shareable.org> <20090506080023.GA7230@kos.to> <20090506110832.GC23364@shareable.org> <20090506120256.GA21149@kos.to> In-Reply-To: <20090506120256.GA21149@kos.to> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Riku Voipio , qemu-devel@nongnu.org Riku Voipio wrote: > 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 :-) > What do we now discuss? A reimplementation of a complete threadsafe user mode for qemu now? I dont think that this is the scope of the two patches. What do the architects of user mode say about that? I thought we have even the problem of a missing qemu user mode Maintainer?