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

[Chris Friesen]

H. Peter Anvin wrote:

> Doing work twice can hardly be considered The Right Thing.

If the alternative is to have apps that can be DOS'd with a single corrupt 
packet, I think that yes, it is.

Going forward, all apps should use nonblocking sockets, correct?  (With the 
current design, because it's the only way to get correctness, with my proposal 
because it's the only way to get full speed.)

Given that, we then have to worry about the installed base of binaries out there 
that will use blocking sockets.  And it's going to take some time before they 
all convert.  For all those binaries, (which include basic things like syslog, 
inetd, portmap, and statd) the existing kernel behaviour does not match what the 
app is expecting.  With a minor change, we can give the behaviour that the app 
expects, though at a performance penalty.  Once the app switches over to 
nonblocking sockets (which it has to do *anyway* under the current model) then 
it gets full performance.

To summarize:
1) apps have to switch to nonblocking sockets  (for correctness)
2) my proposal makes them work as expected in the meantime, with a performance cost


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/