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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list