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

[Chris Friesen <cfriesen@nortelnetworks.com>]

H. Peter Anvin wrote:

> POSIX specifies:

<useful stuff snipped>

> The recvmsg( ) function may fail if:
> 
> [EIO] An I/O error occurred while reading from or writing to the file 
> system.

<snipped>

> Since you didn't code to Linux, and didn't code to POSIX... what did you 
> code to?

I didn't code it--my code generally uses nonblocking sockets or doesn't use 
select at all.  I'm just commenting on existing apps.

What do you mean by "didn't code to Linux"?  The Linux man pages for recvmsg() 
and ip do not mention EIO.  Hence, I suspect that not many people coding for 
Linux will have handled it.  Furthermore, the Linux man page for select() says 
that a socket that is returned as readable will not block on a subsequent read.

>> On the other hand, if you simply do the checksum verification at 
>> select() time for blocking sockets, then the existing binaries get 
>> exactly the behaviour they expect.

> ... unless the blocking changes.  In which case you either have to do 
> work twice, or it might *never* happen.  Not to mention the extra code 
> complexity.

If you verify the checksum at select time, you could just flag the packet as 
verified.  Then even if you do a recvmsg() with MSG_DONTWAIT, you wouldn't have 
to verify it again.  It means an extra pass over the data compared to a full-on 
O_NONBLOCK socket, but it's still correct.

If you change from nonblocking to blocking between select() and recvmsg(), then 
you have a problem, but you're still no worse off than the current situation.

The extra complexity is a valid point, but I suggest that the expectations of 
the installed base are more important.


> The performance overhead of checksumming is substantial; I have seen 
> some real horror examples of what happens when you do it badly.

Again, this is only a backwards compatibility thing.  All new apps should use 
nonblocking sockets anyways, right?  So this way, old apps don't suffer from 
single-packet-DOS attacks, at the cost of a performance penalty.

Chris