On 10/16/19 9:04 AM, Daniel P. Berrangé wrote:
On Wed, Oct 16, 2019 at 06:50:33AM -0500, Eric Blake wrote:
On 10/16/19 4:02 AM, Daniel P. Berrangé wrote:
The challenge here is that we're in between fork + execve and want signal
handlers back to their defaults at time of execve.
If we set SIGPIPE to SIG_IGN and then execve() will that get reset back
to SIG_DFL automatically ?
Sadly, no. execve() does not change whether a signal is ignored or masked
(ignored is more common - a number of CI systems have had issues where the
child inherits SIGPIPE ignored because the parent forgot to reset it, but
the child wasn't expecting it; but inheriting a signal masked is also a real
issue), with the lone exception of SIGCHLD. However, execve() _does_ change
a signal that is being caught in the parent into SIG_DFL post-exec.
That does mean, however, that it is viable to install a no-op SIGPIPE
handler (SIGPIPE is generated but ignored, I/O gets the EPIPE as desired),
then post-exec the new process will have SIG_DFL.
Yeah, that's workable.
So we need virFork() to install a dummy SIGPIPE handler function that
is a no-op, *before* it unmasks signals.
Why mask signals at all? You either mask the signal before I/O, install
the dummy handler, then unmask (and any intermediate SIGPIPE is now
ignored by no-op), or you can merely install the dummy handler before
I/O (any SIGPIPE is ignored by no-op). That is, by the time you
identify a a safe place to install a mask (ie. no I/O between fork() and
that point, but where there will be potential I/O between that point and
exec), with plans to release it later, that same place is just as good
for changing from SIG_IGN to a no-op handler without messing with masks.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
