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

[Chris Friesen]

David S. Miller wrote:
> Chris Friesen <cfriesen@xxxxxxxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/