[Libvir] [patch 9/9] Implement better error reporting
Daniel P. Berrange
berrange at redhat.com
Mon Feb 19 18:22:36 UTC 2007
On Mon, Feb 19, 2007 at 06:13:27PM +0000, Mark McLoughlin wrote:
> On Fri, 2007-02-16 at 19:28 +0000, Daniel P. Berrange wrote:
> > On Fri, Feb 16, 2007 at 02:44:57PM +0000, Mark McLoughlin wrote:
>
> > > @@ -1226,6 +1332,7 @@ static int qemudDispatchPoll(struct qemu
> > >
> > > while (sock) {
> > > struct qemud_socket *next = sock->next;
> > > + /* FIXME: the daemon shouldn't exit on error here */
> > > if (fds[fd].revents)
> > > if (qemudDispatchServer(server, sock) < 0)
> > > return -1;
> >
> > Yes & no. There are two reasons why qemuDispatchServer can fail. Either
> > it can fail to set CLOSEXEC/NONBLOCK mode on the client socket, in
> > which case we could simply drop the client & continue without exiting.
> > If the accept() call fails for anything other than EAGAIN/EINTR then
> > we arguably should exit, because something serious has gone wrong.
>
> Doesn't accept() fail if the client fails to send the final ACK? Do we
> want the daemon to die in that case? Think of an unprivileged user
> connecting to the system daemon's readonly socket ... you really want to
> be paranoid about the daemon exiting as it creates the opportunity for
> unprivileged users to take down guests and networks.
Yes, accept will fail if the client doesn't complete the handshake. I already
(tried) to take care of that case though by not returning an error code if the
errno is EAGAIN
if ((fd = accept(sock->fd, (struct sockaddr *)&addr, &addrlen)) < 0) {
if (errno == EAGAIN)
return 0;
qemudLog(QEMUD_ERR, "Failed to accept connection: %s", strerror(errno));
return -1;
}
Looking at the man page, i think I also need to check for ECONNABORTED
errno value too.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
More information about the libvir-list
mailing list