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

[Chris Friesen]

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
-
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/