how is recv(..., MSG_PEEK) racy?

how is recv(..., MSG_PEEK) racy?

[Abhijit Menon-Sen]

(I'm reposting to linux-kernel because I got no response on netdev.)

I'm trying to understand a fetchmail problem that causes large downloads
from IMAP servers to fail randomly. For some reason, fetchmail uses the
following bizarre code inside a loop to read data from the server:

    if ((n = recv(sock, bp, len, MSG_PEEK)) <= 0)
        return (-1);

    if ((newline = memchr(bp, '\n', n)) != NULL)
        n = newline - bp + 1;

    if ((n = read(sock, bp, n)) == -1)
        return (-1);

The problem occurs (at an unpredictable time, but very often, and with a
greater probability with a larger attachment) when the recv() returns 0,
although tcpdump doesn't show the server closing the connection, or any
other unusual behaviour.

Are there any circumstances other than the connection being closed where
recv(..., MSG_PEEK) can return 0? (Stevens/SUSv3 don't mention any.)

I found the following (paraphrased) comment in net/ipv4/tcp.c:

    if ((flags & MSG_PEEK) && peek_seq != tp->copied_seq) {
        printk(KERN_DEBUG "TCP(%s:%d): Application bug, race in MSG_PEEK.\n",
               current->comm, current->pid);

While fetchmail doesn't seem to be triggering that printk(), I'm curious
about what the race condition is. Google found a post by DaveM saying it
has something to do with URG data, but without any further details. I'd
appreciate any explanation of the problem(s).

Thank you.

-- ams

Re: how is recv(..., MSG_PEEK) racy?

[David S. Miller]

On Tue, 23 Sep 2003 12:15:45 +0530
Abhijit Menon-Sen <ams@wiw.org> wrote:

> While fetchmail doesn't seem to be triggering that printk(), I'm curious
> about what the race condition is. Google found a post by DaveM saying it
> has something to do with URG data, but without any further details. I'd
> appreciate any explanation of the problem(s).

If multiple threads do reads to the same socket, one using
MSG_PEEK and one without, there is a race because the thread
doing MSG_PEEK doesn't expect the bytes it is "peeking" at
to be removed from the receive queue from the socket, but that
is exactly what the other thread will do.

When using URG data, the kernel becomes the "other thread doing
non-MSG_PEEK reads" on the socket.  So if you use MSG_PEEK and
URG data at the same time, you will likely trigger the race and
that printk() alerting you to this fact.