From: Eric Blake <eblake@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
"patches@linaro.org" <patches@linaro.org>,
Samuel Thibault <samuel.thibault@ens-lyon.org>,
Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [Qemu-devel] [PATCH] slirp: fork_exec(): Don't close() a negative number in fork_exec()
Date: Tue, 11 Jul 2017 16:17:42 -0500 [thread overview]
Message-ID: <53d067d6-b52a-a532-9f54-7d079e292a52@redhat.com> (raw)
In-Reply-To: <CAFEAcA-vXYOTm0o4V1XHf1ScuLO9RZesgM+v9FTA71qa9MeBwQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]
On 07/11/2017 03:40 PM, Peter Maydell wrote:
>>>
>>> The problem is you can only bail while you're in the parent
>>> before forking. Once you've started the child there's no
>>> mechanism for dealing with failure.
>>
>> Well, you can always exit the child before anything worse can happen.
>
> You need a mechanism then for causing the parent to notice.
> The current code would leave the parent in a blocking
> accept() call forever (this is what all the XXX comments
> in the current code are about).
You can have the parent create a pipe before forking and does a blocking
read, the child then manages fds and writes success (or failure) to its
end of the pipe (or an early exit causes the parent to read EOF); when
the parent finally gets word on the pipe, then it knows whether the
child is dead-on-arrival due to early setup failures, or whether it is
now safe to block on accept(). But it can easily get more and more
complex the more you want to handle; and if the parent is
multi-threaded, you have to be careful that you only call
async-signal-safe functions in the child between the fork and exec.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2017-07-11 21:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-09 17:54 [Qemu-devel] [PATCH] slirp: fork_exec(): Don't close() a negative number in fork_exec() Peter Maydell
2017-07-11 16:29 ` Dr. David Alan Gilbert
2017-07-11 17:18 ` Peter Maydell
2017-07-11 19:08 ` Dr. David Alan Gilbert
2017-07-11 20:40 ` Peter Maydell
2017-07-11 21:17 ` Eric Blake [this message]
2017-07-11 23:12 ` Samuel Thibault
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=53d067d6-b52a-a532-9f54-7d079e292a52@redhat.com \
--to=eblake@redhat.com \
--cc=dgilbert@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=patches@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=samuel.thibault@ens-lyon.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).