Re: [Xen-devel] [PATCH 20/31] libxl: handle POLLERR, POLLHUP, POLLNVAL properly

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [Xen-devel] [PATCH 20/31] libxl: handle POLLERR, 
POLLHUP, POLLNVAL properly"):
> On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> > +    if (revents & (POLLERR|POLLHUP))
> > +        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 
> > 0);
> 
> If this can happen even when we didn't ask for it then is that really a
> disaster? Could we just log it and move on (or ignore it)?

You never ask for POLLERR or POLLHUP.  They happen regardless.  If
they happen, poll() will keep reporting them.  So we have to stop
polling on this fd entirely - ie effectively the fd has become broken,
unless we know what the cause is and can do something sane about it.
Since this is supposedly the xenstore fd, it is indeed a disaster.

For comparison, if we get eof on the xenstore fd, libxenstore causes
xs_read_watch to return 0 setting errno to EBADF (!) (xs.c:365), which
is also a DISASTER (libxl_event.c:343).

> Under what circumstances does poll actually behave this way? Is it an
> indication that something has gone horribly wrong already?

Yes, exactly.

POLLPRI occurs on sockets and means that the socket has urgent data
(TCP) or out of band data (some other protocols); an application using
TCP would take this as a signal to read data from the fd until it
catches up with the urgent pointer.

POLLHUP occurs when (eg) a pty's other end has been closed and the pty
is shut down.  An application which sees POLLHUP would typically close
the fd.  Eg, in an earlier version of the bootloader rework I had a
bug which would fail to keep an fd open onto the slave side of the
xenconsole pty, so libxl would get POLLHUP on the master side the
bootloader execution would be aborted.  This was handy for my error
testing :-) and is an example of a POLLHUP which isn't a DISASTER,
although it is pretty fatal for the fd in question.

These events should not occur on the xenstore handle.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel