sct's stance on race conditions between close(), accept(), and sigwaitinfo()
in sigio-based programs can be summed up as "Oh, don't worry about
ghost events, you should be prepared for read() to return EWOULDBLOCK".
This works for POLL_IN and POLL_OUT events. But Julian points out that
it might be hard to ignore POLL_ERR and POLL_HUP events in the same way.
Maybe we do need marker events for fd creation and/or deletion after all...
sct, what say ye?
- Dan "Chicken Little" Kegel
Julian Anastasov <uli@linux.tu-varna.acad.be> wrote:
> With current behavior, when we receive POLL_HUP we know
> that the remote end closed its end of the connection. But what
> if we can't wait remote end to close the connection and we close()
> the socket, even after shutdown(fd,1). After our close() when the
> fd is released and can be reused again it is still possible unread
> events to stay in the rt queue (POLL_IN in this case). When we
> create/accept new file descriptor (with the same value) and continue
> to read the events (from the long long rt queue) using sigwaitinfo(),
> we can dequeue unexpected notifications for the old file descriptor.
>
> For example:
>
> <-- POLL_IN for fd
> sigwaitinfo(): POLL_IN for fd
> read(fd)=100
> // We remember that we can write(), so we try to write()
> write(fd)=100
> shutdown(fd,1)
> // We wait remote end to close
> // Here we expect POLL_IN but it is not received (after some
> // timeout)
> <-- POLL_IN for the listener enqueue
> <-- POLL_IN/POLL_ERR enqueued after our last check of
> the rt queue
> // We decide to close(fd)
> close(fd)
> sigwaitinfo(): POLL_IN for the listener
> fd = accept()
> set fd FASYNC, ... (or inherited from accept)
> sigwaitinfo(): POLL_IN/POLL_ERR for the old fd but we think it
> is for the new fd. Not fatal, one extra read()=EAGAIN
>
> What if we receive POLL_ERR from old fd when the new fd is
> in connecting state? We think the connection failed for the
> new fd. FATAL!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:12 EST