lkml.org 
[lkml]   [2004]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: UDP recvmsg blocks after select(), 2.6 bug?
    On Wed, Oct 06, 2004 at 08:04:29PM +0200, Joris van Rantwijk wrote:

    > > On Mer, 2004-10-06 at 15:52, Joris van Rantwijk wrote:
    > > > 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.

    Alan answers - and I don't like his answer a bit:

    > > Select indicates there may be data. That is all - it might also be an
    > > error, it might turn out to be wrong.
    > >
    > > You should always combine select with nonblocking I/O

    Joris replies again:

    > Sorry about my wrongly blaming the kernel. I do think this issue shows hat
    > the select(2) manual needs fixing.

    It may need fixing in the sense that it must point out that the Linux kernel
    might not conform to POSIX in its handling of select on sockets.

    We now not only have "man 2 select", but also "man 3p select".
    This is the POSIX text:

    A descriptor shall be considered ready for reading when a
    call to an input function with O_NONBLOCK clear would not
    block, whether or not the function would transfer data
    successfully. (The function might return data, an end-of-
    file indication, or an error other than one indicating
    that it is blocked, and in each of these cases the
    descriptor shall be considered ready for reading.)

    As far as I can interpret these sentences, Linux does not conform.

    Andries


    Neil Horman wrote:

    >> I think you could also pass the MSG_ERRQUEUE flag to the recvfrom call
    >> and receive the errored frame, eliminating the case where errored frames
    >> might cause you to block on a read after a good return from a select call.

    davem wrote:

    >> There is no such guarentee.

    >> Incorrect UDP checksums could cause the read data to
    >> be discarded. We do the copy into userspace and checksum
    >> computation in parallel. This is totally legal and we've
    >> been doing it since 2.4.x first got released.


    ahu wrote:

    >> This can happen, and is fully to be expected. For a host of reasons the
    >> packet might not in fact appear. Whenever using select for non-blocking IO
    >> always set your sockets to non-blocking as well.

    >> One of the legitimate reasons is the reception of packets which, on copying,
    >> turn out to have a bad checksum.

    >> Stevens has a section on this, recommended reading.

    Reference?
    -
    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:4.068 / U:0.424 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site