]> git.ipfire.org Git - thirdparty/libvirt.git/commit
command: avoid potential deadlock on handshake
authorEric Blake <eblake@redhat.com>
Sat, 26 May 2012 02:17:01 +0000 (20:17 -0600)
committerEric Blake <eblake@redhat.com>
Thu, 7 Jun 2012 15:25:38 +0000 (09:25 -0600)
commit5e8ab3915b5f979f049547565805174ec7cd79b8
tree1df899537b7a090eb9f4b558e8c54fccb9086ebb
parentbda2f17d7e673f4dd7fc1a03389ca7d8f4e1646e
command: avoid potential deadlock on handshake

There is a theoretical problem of an extreme bug where we can get
into deadlock due to command handshaking.  Thanks to a pair of pipes,
we have a situation where the parent thinks the child reported an
error and is waiting for a message from the child to explain the
error; but at the same time the child thinks it reported success
and is waiting for the parent to acknowledge the success; so both
processes are now blocked.

Thankfully, I don't think this deadlock is possible without at
least one other bug in the code, but I did see exactly that sort
of situation prior to commit da831af - I saw a backtrace where a
double close bug in the parent caused the parent to read from the
wrong fd and assume the child failed, even though the child really
sent success.

This potential deadlock is not quite like commit 858c247 (a deadlock
due to multiple readers on one pipe preventing a write from completing),
although the solution is similar - always close unused pipe fds before
blocking, rather than after.

* src/util/command.c (virCommandHandshakeWait): Close unused fds
sooner.
src/util/command.c