lkml.org 
[lkml]   [2004]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectUDP recvmsg blocks after select(), 2.6 bug?
    Hello,

    I have a problem where the sequence of events is as follows:
    - application does select() on a UDP socket descriptor
    - select returns success with descriptor ready for reading
    - application does recvfrom() on this descriptor and this recvfrom()
    blocks forever

    My understanding of POSIX is limited, but it seems to me that a read call
    must never block after select just said that it's ok to read from the
    descriptor. So any such behaviour would be a kernel bug.

    This problem occurs repeatedly, but only once per week on average so it is
    hard to debug but definitely a real problem. I know for a fact that the
    sequence of events is as described above from strace output. My kernel
    version is 2.6.7.

    From a brief look at the kernel UDP code, I suspect a problem in
    net/ipv4/udp.c, udp_recvmsg(): it reads the first available datagram
    from the queue, then checks the UDP checksum. If the UDP checksum fails at
    this point, the datagram is discarded and the process blocks until the next
    datagram arrives.

    Could someone please help me track this problem?
    Am I correct in my reasoning that the select() -> recvmsg() sequence must
    never block?
    If yes, is it possible that this problem is triggered by a failed UDP
    checksum in the udp_recvmsg() function?
    If yes, can we do something to fix this?

    Thanks,
    Joris.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:06    [W:0.021 / U:0.436 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site