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

Chris Friesen
2004-10-06T20:16:24Z

Hua Zhong wrote:

>>>How hard is it to treat the next read to the fd as
>>NON_BLOCKING, even if it's not set?
>>
>>Userspace likely would not properly handle EAGAIN on a
>>nonblocking socket.

I meant blocking, of course, but you caught that.

> But it's better than blocking the call, isn't it?
>
> If the caller is using NON_BLOCKING already, no change in behavior,
> otherwise it returns an error which the app may or may not handle, instead
> of blocking it (which is usually fatal). Plus it hopefully gives Posix
> compliance.

From what Andries posted, we can't block. If select says its readable, we can
"return data, an end-of-file indication, or an error other than one
indicating that it is blocked".

We have no data, network sockets don't have end-of-file indication (or would
returning a length of zero count?), and there is no other suitable errno that I saw.

> I can see there could be remote DoS attacks by just sending malformed UDP
> packets.

Yep.

Chris