According to this lkml thread, select() can return that a file descriptor is available for reading, but reading from that descriptor will block, and this is perfectly valid. As ahu says, “Whenever using select for non-blocking IO always set your sockets to non-blocking as well.”
Good to know…
Muli Ben-Yehuda's journal 
It’s fairly UDP specific though, no?
Comment by hasturkun — October 6, 2004 @ 12:41 PM |
No, it can happen with accept as well.
Comment by mulix — October 8, 2004 @ 6:06 AM |
Punishment for the Original Sin of overloaded meaning
Apparently, the original sin was to indicate end-of-file by receipt of 0 data bytes, rather than by some error return.
So sockets have no way to say “Oops. I thought I have data for you when you called select(). However this data turned out to be invalid when I checked it as it was being copied to your user area, and I was forced to discard it” except by blocking.
Comment by tddpirate — October 6, 2004 @ 3:02 PM |
Re: Punishment for the Original Sin of overloaded meaning
i wonder how often data ends up being invalid upon receipt?
Comment by nealsid — October 7, 2004 @ 10:37 AM |
Re: Punishment for the Original Sin of overloaded meaning
From the lkml discussions, I understand that either this happens very rarely, or if it happens, then usually there is another packet so threads do not get blocked for long time.
At any case, I smell causal relationship between the rarity of this case and the failure of the ABI to handle it in a clean and straightforward way.
Comment by tddpirate — October 7, 2004 @ 4:13 PM
Re: Punishment for the Original Sin of overloaded meaning
not too often, as can be seen by the fact that both 2.4 and 2.6 kernels behave this way, and only now someone bothered to mention it… I would imagine that that a new packet appears pretty soon after the discarded, so the application doesn’t “realize” that it has been blocked.
Comment by mulix — October 8, 2004 @ 6:07 AM
Re: Punishment for the Original Sin of overloaded meaning
The case raised in the lkml is that the problem happens mostly if the UDP packet checksum is incorrect, which is easy to exploit for DoS since you only need to generate a UDP packet with incorrect checksum.
The point where it fails and the “next packet is due soon” is when you look at DNS with a single packet request and single packet reply, another packet won’t come soon. So if the caller doesn’t use O_NONBLOCK and doesn’t setup proper timeouts he’d be stuck in DoS land.
– Baruch
Comment by Anonymous — October 9, 2004 @ 10:20 PM
Re: Punishment for the Original Sin of overloaded meaning
isn’t that what EAGAIN means (amongst other things)? but EAGAIN is only valid on non-blocking sockets.
Comment by mulix — October 8, 2004 @ 6:06 AM |