[libvirt] [PATCH] Ignore SIGWINCH in remote client call to poll(2) (RHBZ#567931).

[Paolo Bonzini]

On 02/24/2010 04:09 PM, Richard W.M. Jones wrote:
>> No signal handler will necessarily do things like
>> >  longjmp-ing out of the remote driver, so every signal could give rise to
>> >  a similar bug.
> Did you mean "signals handlers might longjmp out ..."?

No, I meant what I wrote, as longjmp-ing out is the only way to handle 
signals if you do not have control on the whole code and if you cannot 
audit the handling of EINTR in each non-restartable system call (notably 
select/poll).  Setting a flag doesn't work in this case.

Of course, longjmp would have another share of problems since it would 
likely leave libvirt's state inconsistent, as in the CERT page that you 
linked.

>> >  In particular, SIGCHLD would be an obvious candidate for being handled
>> >  the same way, since both SIGWINCH and SIGCHLD are default-ignored
>> >  signals.  On the other hand, while for SIGWINCH it would be mostly
>> >  harmless(*), for SIGCHLD it would leave a zombie until the remote
>> >  libvirtd answers.  Any ideas?
>> >
>> >      (*) Unless you have more than one thread using curses, and a thread
>> >      other than the one calling libvirt has blocked SIGWINCH.
>
> Certainly SIGCHLD could be added.  I was keeping this patch minimal so
> it just fixes the problem I observed, to reduce the chance that a
> change to such a critical piece of code could break anything else.

Yep, I agree.

Paolo