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

From: David S. Miller (davem_at_redhat.com)
Date: 09/23/03

  • Next message: Joe Thornber: "Re: [PATCH] DM 1/6: Use new format_dev_t macro" 
    Date:	Tue, 23 Sep 2003 00:33:57 -0700
To: Abhijit Menon-Sen <ams@wiw.org>

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

  • Next message: Joe Thornber: "Re: [PATCH] DM 1/6: Use new format_dev_t macro"

    Relevant Pages