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

[Daniel P. Berrange]

On Wed, Feb 24, 2010 at 03:09:54PM +0000, Richard W.M. Jones wrote:
> On Wed, Feb 24, 2010 at 03:39:20PM +0100, Paolo Bonzini wrote:
> > On 02/24/2010 02:06 PM, Richard W.M. Jones wrote:
> >> The correct solution is to mask out SIGWINCH for the duration
> >> of the poll(2) system call.  The per-thread mask is changed and
> >> restored immediately after the call.  Since we are using
> >> pthread_sigmask, this should not affect other threads, and
> >> since we restore the signal mask immediately afterwards it should
> >> not affect the current thread visibly either.
> >
> > This is interesting.  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 ..."?  I've seen a
> few in my time that have done that.  I notice the top Google hit for
> "signal handler" & "longjmp" is this warning about the practice from
> CERT:
> 
> https://www.securecoding.cert.org/confluence/display/seccode/SIG32-C.+Do+not+call+longjmp%28%29+from+inside+a+signal+handler
> 
> > 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.

I think SIGWINCH + SIGCHLD + SIGPIPE are a reasonably set to block
since those are common "normal" signals a process may received during
operation. Other signals are all typically related to fatal problems
rather tha normal conditions


Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|