Muli Ben-Yehuda's journal

October 6, 2004

From the “I didn’t know that” Dept

Filed under: Uncategorized — Muli Ben-Yehuda @ 5:29 PM

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…

8 Comments »

  1. It’s fairly UDP specific though, no?

    Comment by hasturkun — October 6, 2004 @ 12:41 PM | Reply

    • No, it can happen with accept as well.

      Comment by mulix — October 8, 2004 @ 6:06 AM | Reply

  2. 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 | Reply

    • 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 | Reply

      • 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 | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: