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