I was installing cups yesterday, as I found a rare occasion where I actually needed to use the printer. It immediately fell foul of my kernel patch to detected select(2) on blocking sockets. For the background to this, see this linux-kernel thread, where Linux's behaviour is discussed in depth: to cut a long story short, Linux doesn't guarantee that a read(2) or recvmsg(2) on a socket won't block even if select says there is data on that socket. This is because UDP, for instance, is a datagram protocol, and is allowed to discard packets at any time, even after they have been "seen" by a select(2).

So I filed Debian bug 284501 yesterday. I have already been responsible for the fixes for this issue to inetd and syslog. The list of applications bitten by this behaviour change just gets longer. I should put my kernel patch up here soon — it's an even more gross hack than my /tmp race detector, but it does the job well enough. But perhaps I should modify it to only report UDP sockets; while TCP sockets are theoretically vulnerable, in practice it's UDP which is easily DoSed using hping2.

Don't get me wrong: I, for one, welcome our new insect overlords... erm, that is, I like the new behaviour. If a program wants not to block on a socket, it should make it non-blocking. But surely introducing this change, which breaks so many applications, when the benefits are essentially a small micro-optimisation for VoIP and realmedia users — surely we are insane to make this tradeoff? How about fixing the applications first, next time? Surely the people who needed the speedup should have been responsible for doing the background work, so other users were not negatively affected by it?