From: Jamie Lokier <jamie@shareable.org>
To: Scott Tsai <scottt.tw@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Don't leak file descriptors
Date: Mon, 16 Nov 2009 02:15:39 +0000 [thread overview]
Message-ID: <20091116021539.GA9827@shareable.org> (raw)
In-Reply-To: <ef2f888d0911130736u18686ae3u631f9e97d1592357@mail.gmail.com>
Scott Tsai wrote:
> On Fri, Nov 13, 2009 at 11:17 PM, Kevin Wolf <kwolf@redhat.com> 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
next prev parent reply other threads:[~2009-11-16 2:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-13 15:17 [Qemu-devel] [PATCH] Don't leak file descriptors Kevin Wolf
2009-11-13 15:36 ` Scott Tsai
2009-11-16 2:15 ` Jamie Lokier [this message]
2009-11-13 15:41 ` Nathan Froyd
2009-11-13 15:44 ` Kevin Wolf
2009-11-13 21:05 ` Blue Swirl
2009-11-16 12:47 ` Kevin Wolf
2009-11-16 16:21 ` Blue Swirl
2009-11-16 16:46 ` Avi Kivity
2009-11-16 23:05 ` Jamie Lokier
2009-11-16 23:10 ` Jamie Lokier
2009-11-17 9:12 ` Kevin Wolf
2009-11-17 20:28 ` Blue Swirl
2009-11-16 23:26 ` Anthony Liguori
2009-11-16 23:44 ` Jamie Lokier
2009-11-17 9:00 ` Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091116021539.GA9827@shareable.org \
--to=jamie@shareable.org \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=scottt.tw@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.