[libvirt] [PATCH] lxc_controller.c: don't ignore failed "accept"

coverity complained (rightly) about the risk of closing a negative file descriptor. However, the real problem was the missing test for a failed "accept" call. I'm not 100% sure that a failed accept call deserves to provoke a "goto cleanup", but doing that is consistent with what the nearby code does upon epoll_ctl failure.
From 8bfd81f0a8a9cb3fd9b575e9c2f5ab9969a2910f Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering@redhat.com> Date: Tue, 2 Feb 2010 11:55:19 +0100 Subject: [PATCH] lxc_controller.c: don't ignore failed "accept"
* src/lxc/lxc_controller.c (lxcControllerMain): A failed accept could lead to passing a negative file descriptor to various other functions, which would in turn report EBADF, rather that whatever error prompted the initial failure. --- src/lxc/lxc_controller.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c index 6304815..682f874 100644 --- a/src/lxc/lxc_controller.c +++ b/src/lxc/lxc_controller.c @@ -349,6 +349,11 @@ static int lxcControllerMain(int monitor, if (numEvents > 0) { if (epollEvent.data.fd == monitor) { int fd = accept(monitor, NULL, 0); + if (fd < 0) { + virReportSystemError(NULL, errno, "%s", + _("accept(monitor,...) failed")); + goto cleanup; + } if (client != -1) { /* Already connected, so kick new one out */ close(fd); continue; -- 1.7.0.rc1.149.g0b0b7

On Tue, Feb 02, 2010 at 11:58:44AM +0100, Jim Meyering wrote:
coverity complained (rightly) about the risk of closing a negative file descriptor. However, the real problem was the missing test for a failed "accept" call. I'm not 100% sure that a failed accept call deserves to provoke a "goto cleanup", but doing that is consistent with what the nearby code does upon epoll_ctl failure.
This isn't correct because the incoming client can quit between the time of poll() indicating its presence, and accept() trying to process it. This is an expected non-fatal scenario, so it should just be ignored without quitting. epoll_ctl() by comparison is a fatal system error, so has to be handled as an unrecoverable error Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Daniel P. Berrange wrote:
On Tue, Feb 02, 2010 at 11:58:44AM +0100, Jim Meyering wrote:
coverity complained (rightly) about the risk of closing a negative file descriptor. However, the real problem was the missing test for a failed "accept" call. I'm not 100% sure that a failed accept call deserves to provoke a "goto cleanup", but doing that is consistent with what the nearby code does upon epoll_ctl failure.
This isn't correct because the incoming client can quit between the time of poll() indicating its presence, and accept() trying to process it. This is an expected non-fatal scenario, so it should just be ignored without quitting. epoll_ctl() by comparison is a fatal system error, so has to be handled as an unrecoverable error
Ok, so some errno values are ignorable. Do you also want to ignore the likes of EMFILE, ENFILE, EPERM, etc? Otherwise, I propose to enumerate "ignorable-errno" values and treat any others as unrecoverable. Do you know which errno values should be ignored?
participants (2)
-
Daniel P. Berrange
-
Jim Meyering