[libvirt] [PATCH] vircommand: fix polling in virCommandProcessIO
When running on FreeBSD, there's a bug in virCommandProcessIO polling that is triggered by the commandtest. A test that triggers EPIPE in commandtest (named "test20") hungs forever on FreeBSD. Apparently, this happens because FreeBSD sets POLLHUP flag on revents when stdin in closed. And as the current implementation only checks for POLLOUT and POLLERR, it ends up looping forever inside virCommandProcessIO and not trying to do one more write() that would trigger EPIPE. To fix that check for the POLLHUP flag along with POLLOUT and POLLERR. --- src/util/vircommand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/vircommand.c b/src/util/vircommand.c index 648f5ed..f9b3c3f 100644 --- a/src/util/vircommand.c +++ b/src/util/vircommand.c @@ -2097,7 +2097,7 @@ virCommandProcessIO(virCommandPtr cmd) } } - if (fds[i].revents & (POLLOUT | POLLERR) && + if (fds[i].revents & (POLLOUT | POLLHUP | POLLERR) && fds[i].fd == cmd->inpipe) { int done; -- 2.3.5
On Tue, Apr 21, 2015 at 08:19:45PM +0300, Roman Bogorodskiy wrote:
When running on FreeBSD, there's a bug in virCommandProcessIO polling that is triggered by the commandtest.
A test that triggers EPIPE in commandtest (named "test20") hungs forever on FreeBSD.
Apparently, this happens because FreeBSD sets POLLHUP flag on revents when stdin in closed. And as the current implementation only checks for POLLOUT and POLLERR, it ends up looping forever inside virCommandProcessIO and not trying to do one more write() that would trigger EPIPE.
To fix that check for the POLLHUP flag along with POLLOUT and POLLERR.
We're already checking that for the pipe heading the other way and according to information I found it makes sense to do this, even though it seems that according to documentation this shouldn't happen. ACK
--- src/util/vircommand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/vircommand.c b/src/util/vircommand.c index 648f5ed..f9b3c3f 100644 --- a/src/util/vircommand.c +++ b/src/util/vircommand.c @@ -2097,7 +2097,7 @@ virCommandProcessIO(virCommandPtr cmd) } }
- if (fds[i].revents & (POLLOUT | POLLERR) && + if (fds[i].revents & (POLLOUT | POLLHUP | POLLERR) && fds[i].fd == cmd->inpipe) { int done;
-- 2.3.5
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Martin Kletzander wrote:
On Tue, Apr 21, 2015 at 08:19:45PM +0300, Roman Bogorodskiy wrote:
When running on FreeBSD, there's a bug in virCommandProcessIO polling that is triggered by the commandtest.
A test that triggers EPIPE in commandtest (named "test20") hungs forever on FreeBSD.
Apparently, this happens because FreeBSD sets POLLHUP flag on revents when stdin in closed. And as the current implementation only checks for POLLOUT and POLLERR, it ends up looping forever inside virCommandProcessIO and not trying to do one more write() that would trigger EPIPE.
To fix that check for the POLLHUP flag along with POLLOUT and POLLERR.
We're already checking that for the pipe heading the other way and according to information I found it makes sense to do this, even though it seems that according to documentation this shouldn't happen.
ACK
Pushed, thanks! Roman Bogorodskiy
participants (2)
-
Martin Kletzander -
Roman Bogorodskiy