[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]