From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N9r88-0007IQ-Un for qemu-devel@nongnu.org; Sun, 15 Nov 2009 21:15:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N9r84-0007EJ-8v for qemu-devel@nongnu.org; Sun, 15 Nov 2009 21:15:48 -0500 Received: from [199.232.76.173] (port=58562 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N9r84-0007EG-2o for qemu-devel@nongnu.org; Sun, 15 Nov 2009 21:15:44 -0500 Received: from mail2.shareable.org ([80.68.89.115]:58600) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N9r83-0004Ng-Rn for qemu-devel@nongnu.org; Sun, 15 Nov 2009 21:15:44 -0500 Date: Mon, 16 Nov 2009 02:15:39 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Don't leak file descriptors Message-ID: <20091116021539.GA9827@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Scott Tsai Cc: Kevin Wolf , qemu-devel@nongnu.org Scott Tsai wrote: > On Fri, Nov 13, 2009 at 11:17 PM, Kevin Wolf wrote: > > We're leaking file descriptors to child processes. Set FD_CLOEXEC on file > > descriptors that don't need to be passed to children to stop this misbehaviour. > > Since qemu is a multi threaded program, how about opening those file > descriptors with the equivalent of O_CLOEXEC set to avoid the race > condition when a fork comes between the 'open/socket/accept' operation > and the 'fcntl'? For qemu-system this shoudn't matter, as long as all the forking and opening is done in the same thread, with other threads only used for virtual CPUs. For qemu-user, maybe it's relevant? > We could create helper functions like 'qemu_socket_cloexec'. > The implementation of qemu_socket_cloexec would use the new system > calls and flags listed in: > http://udrepper.livejournal.com/20407.html > if available and fall back to separate 'open' and 'fcnt' operations > when not building with a new enough glibc. To do it thoroughly, it's possible to emulate O_CLOEXEC's thread-safety, by blocking fork operations in other threads during an open+fcntl sequence using an rwlock, or without locking by keeping track of "possibly open" file descriptors and closing them unconditionally in fork children. That would help with qemu-user emulation of O_CLOEXEC (et al) too. -- Jamie