Scott Tsai wrote: > On Fri, Nov 13, 2009 at 11:17 PM, Kevin Wolf <kw...@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