Re: UDP recvmsg blocks after select(), 2.6 bug?

Chris Friesen
2004-10-07T22:27:52Z

David S. Miller wrote:
> Chris Friesen <cfriesen@nortelnetworks.com> wrote:

>>In this case, select() returns with the socket readable, we call recvmsg() and
>>discover the message is corrupt. At this point we throw away the corrupt
>>message, so we now have no data waiting to be received. We return EAGAIN, and
>>userspace goes merrily on its way, handling anything else in its loop, then
>>going back to select().

> Incorrect. When the user specifies blocking on the file descriptor
> we must give it what it asked for. -EAGAIN on a blocking file descriptor
> is always a bug, in all situations, that's what this code used to do and we
> fixed it because it's a bug.

I believe you misread what I said. Just before the above quote, I said "We are
discussing the case where the socket is nonblocking and the udp checksum is
corrupt, right? "

What I had in mind was that the non-blocking file descriptor have select()
return without verifying the checksum, and if it was discovered to be bad at
recvmsg() time, we return EAGAIN. For a blocking file descriptor, we would
verify the checksum before returning from select().

That way, the blocking case gets the semantics it expects (although worse
performance), while the nonblocking case gets full performance as well as
semantics that it will handle properly.

Chris