From: "Martijn Sipkema" <msipkema@sipkema-digital.com>
To: "Paul Jakma" <paul@clubi.ie>
Cc: "Chris Friesen" <cfriesen@nortelnetworks.com>,
"Richard B. Johnson" <root@chaos.analogic.com>,
"David S. Miller" <davem@davemloft.net>, <joris@eljakim.nl>,
<linux-kernel@vger.kernel.org>
Subject: Re: UDP recvmsg blocks after select(), 2.6 bug?
Date: Thu, 7 Oct 2004 15:07:29 +0100 [thread overview]
Message-ID: <001c01c4ac76$fb9fd190$161b14ac@boromir> (raw)
In-Reply-To: Pine.LNX.4.61.0410071346040.304@hibernia.jakma.org
From: "Paul Jakma" <paul@clubi.ie>
Sent: Thursday, October 07, 2004 13:53
> On Thu, 7 Oct 2004, Martijn Sipkema wrote:
>
> > That there is time between the select() and recvmsg() calls is not
> > the issue; the data is only checked in the call to recvmsg().
> > Actually the longer the time between select() and recvmsg(), the
> > larger the probability that valid data has been received.
>
> But it is the issue.
>
> Much can change between the select() and recvmsg - things outside of
> kernel control too, and it's long been known.
There is no change; the current implementation just checks the validity of
the data in the recvmsg() call and not during select().
> > But the standard clearly says otherwise.
>
> Standards can have bugs too.
>
> It's not healthy to take a corner-case situation from the standard on
> select() and apply it globally to all IO. (not in my mind anyway,
> whatever the standard says).
Read the standard. The behavious of select() on sockets is explicitely
described.
> > Perhaps select()'s perception of state should be made to take possible
> > corruption into account.
>
> You'll /still/ run into problems, on other platforms too. Set socket
> to O_NONBLOCK and deal with it ;)
What problems?
> > Why would the POSIX standard say recvmsg() should not block if
> > it did not intend it to be used in that way?
>
> POSIX_ME_HARDER? ;)
Would you care to provide any real answers or are you just telling
me to shut up because whatever Linux does is good, and not appear
unreasonable by adding a ;) ..?
> > Wrong. IMHO it is not exactly a good thing to not be compliant on
> > such basic functionality.
>
> Like I said, to my mind, any sane app should try avoiding assumption
> that kernel state remains same between select() and read/write - and
> O_NONBLOCK exists to deal nicely with the situation.
>
> You really shouldnt assume select state is guaranteed not to change
> by time you get round to doing IO. It's not safe, and not just on
> Linux - whatever POSIX says.
Any sane application would be written for the POSIX API as described
in the standard, and a sane kernel should IMHO implement that standard
whenever possible.
--ms
next prev parent reply other threads:[~2004-10-07 13:13 UTC|newest]
Thread overview: 191+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-06 14:52 UDP recvmsg blocks after select(), 2.6 bug? Joris van Rantwijk
2004-10-06 15:01 ` David S. Miller
2004-10-06 15:13 ` Chris Friesen
2004-10-06 15:15 ` Richard B. Johnson
2004-10-06 15:21 ` David S. Miller
2004-10-06 15:29 ` Richard B. Johnson
2004-10-06 15:42 ` David S. Miller
2004-10-06 15:57 ` Chris Friesen
2004-10-06 15:44 ` Lars Marowsky-Bree
2004-10-07 1:16 ` Paul Jakma
2004-10-07 7:10 ` Chris Friesen
2004-10-07 11:53 ` Paul Jakma
2004-10-07 13:32 ` Martijn Sipkema
2004-10-07 12:53 ` Paul Jakma
2004-10-07 13:12 ` Richard B. Johnson
2004-10-07 14:07 ` Martijn Sipkema [this message]
2004-10-07 13:19 ` Paul Jakma
2004-10-07 13:36 ` Paul Jakma
2004-10-07 15:01 ` Jean-Sebastien Trottier
2004-10-07 16:20 ` Chris Friesen
2004-10-07 18:20 ` Hua Zhong
2004-10-07 18:33 ` Chris Friesen
2004-10-07 22:41 ` Martijn Sipkema
2004-10-07 21:49 ` Chris Friesen
2004-10-07 22:00 ` David S. Miller
2004-10-07 22:24 ` Chris Friesen
2004-10-07 22:26 ` David S. Miller
2004-10-07 22:39 ` Chris Friesen
2004-10-07 22:42 ` David S. Miller
2004-10-07 23:27 ` Chris Friesen
2004-10-08 0:04 ` Ben Greear
2004-10-08 2:51 ` Mark Mielke
2004-10-08 3:39 ` David S. Miller
2004-10-08 3:48 ` Mark Mielke
2004-10-08 3:59 ` David S. Miller
2004-10-07 23:19 ` Martijn Sipkema
2004-10-07 22:24 ` David S. Miller
2004-10-07 22:33 ` Alan Curry
2004-10-07 22:42 ` Mark Mielke
2004-10-07 22:47 ` David S. Miller
2004-10-07 23:00 ` Mark Mielke
2004-10-07 23:07 ` David S. Miller
2004-10-08 6:10 ` Theodore Ts'o
2004-10-08 15:20 ` Mark Mielke
2004-10-08 0:37 ` Lee Revell
2004-10-07 22:46 ` Hua Zhong
2004-10-07 22:48 ` David S. Miller
2004-10-07 23:17 ` Martijn Sipkema
2004-10-07 13:45 ` Alan Cox
2004-10-07 16:32 ` Martijn Sipkema
2004-10-07 14:50 ` Alan Cox
2004-10-07 21:58 ` mmap specification - was: ... select specification Andries Brouwer
2004-10-07 22:17 ` Chris Wedgwood
2004-10-07 22:34 ` Andries Brouwer
2004-10-07 22:32 ` Kyle Moffett
2004-10-07 22:46 ` Andries Brouwer
2004-10-07 23:30 ` Kyle Moffett
2004-10-08 9:19 ` Andries Brouwer
2004-10-09 21:10 ` Martijn Sipkema
2004-10-07 13:48 ` UDP recvmsg blocks after select(), 2.6 bug? Alan Cox
2004-10-07 14:57 ` Richard B. Johnson
2004-10-07 15:18 ` Adam Heath
2004-10-07 16:39 ` Martijn Sipkema
2004-10-07 16:09 ` Mark Mielke
2004-10-07 17:18 ` Chris Friesen
2004-10-06 15:31 ` Chris Friesen
2004-10-06 15:41 ` David S. Miller
2004-10-06 16:07 ` Richard B. Johnson
2004-10-06 16:57 ` Neil Horman
2004-10-06 15:59 ` Paul Jackson
2004-10-06 16:35 ` Martijn Sipkema
2004-10-06 15:30 ` Chris Friesen
2004-10-06 15:09 ` Richard B. Johnson
2004-10-06 15:18 ` bert hubert
2004-10-06 16:41 ` Alan Cox
2004-10-06 18:04 ` Joris van Rantwijk
2004-10-06 19:30 ` Andries Brouwer
2004-10-06 19:23 ` Alan Cox
2004-10-06 22:08 ` Martijn Sipkema
2004-10-06 20:25 ` Alan Cox
2004-10-06 22:15 ` Andries Brouwer
2004-10-06 22:32 ` David S. Miller
2004-10-06 23:25 ` YOSHIFUJI Hideaki / 吉藤英明
2004-10-06 23:11 ` Willy Tarreau
2004-10-06 19:43 ` Hua Zhong
2004-10-06 19:54 ` Chris Friesen
2004-10-06 19:59 ` Hua Zhong
2004-10-06 20:10 ` Chris Friesen
2004-10-06 21:45 ` Martijn Sipkema
2004-10-06 23:35 ` David S. Miller
2004-10-06 20:06 ` David S. Miller
2004-10-06 20:18 ` Chris Friesen
2004-10-06 20:26 ` Hua Zhong
2004-10-06 20:38 ` Andries Brouwer
2004-10-06 20:58 ` Joris van Rantwijk
2004-10-06 22:29 ` David S. Miller
2004-10-07 16:08 ` Adrian Phillips
2004-10-06 20:06 ` Olivier Galibert
2004-10-06 23:35 ` David S. Miller
2004-10-07 0:19 ` Olivier Galibert
2004-10-07 0:29 ` David S. Miller
2004-10-07 10:56 ` Martijn Sipkema
2004-10-08 6:41 ` Willy Tarreau
2004-10-08 15:27 ` Mark Mielke
2004-10-15 22:42 ` Robert White
2004-10-15 23:33 ` David Schwartz
2004-10-16 0:59 ` Chris Friesen
2004-10-16 2:35 ` Mark Mielke
2004-10-16 4:23 ` David Schwartz
2004-10-16 4:35 ` Mark Mielke
2004-10-16 4:58 ` David Schwartz
2004-10-16 6:25 ` Mark Mielke
2004-10-16 21:44 ` Roland Kuhn
2004-10-17 0:06 ` Mark Mielke
2004-10-17 0:30 ` David Schwartz
2004-10-17 14:47 ` Mark Mielke
2004-10-17 0:28 ` David Schwartz
2004-10-17 13:35 ` Lars Marowsky-Bree
2004-10-17 14:17 ` Buddy Lucas
2004-10-17 15:05 ` Mark Mielke
2004-10-17 15:40 ` Buddy Lucas
2004-10-17 16:13 ` Lee Revell
2004-10-17 17:35 ` Jesper Juhl
2004-10-17 18:04 ` Buddy Lucas
2004-10-17 18:06 ` Lars Marowsky-Bree
2004-10-17 18:21 ` Buddy Lucas
2004-10-17 20:04 ` Martijn Sipkema
2004-10-17 20:08 ` Lars Marowsky-Bree
2004-10-17 17:35 ` Martijn Sipkema
2004-10-17 17:33 ` Buddy Lucas
2004-10-17 19:58 ` Martijn Sipkema
2004-10-17 19:33 ` Buddy Lucas
2004-10-17 20:11 ` Lars Marowsky-Bree
2004-10-17 20:25 ` Buddy Lucas
2004-10-17 20:42 ` Martijn Sipkema
2004-10-17 20:02 ` Buddy Lucas
2004-10-17 18:53 ` David Schwartz
2004-10-17 19:26 ` Hua Zhong
2004-10-17 20:32 ` Martijn Sipkema
2004-10-17 19:21 ` Hua Zhong
2004-10-17 17:22 ` Lars Marowsky-Bree
2004-10-17 17:54 ` Buddy Lucas
2004-10-17 18:05 ` Lars Marowsky-Bree
2004-10-17 18:06 ` Mark Mielke
2004-10-20 21:31 ` H. Peter Anvin
2004-10-20 21:58 ` Chris Friesen
2004-10-20 22:00 ` H. Peter Anvin
2004-10-20 22:12 ` Chris Friesen
2004-10-20 23:16 ` David Schwartz
2004-10-21 1:03 ` Chris Friesen
2004-10-21 1:38 ` David Schwartz
2004-10-21 3:01 ` Michael Clark
2004-10-21 3:52 ` Michael Clark
2004-10-21 4:10 ` H. Peter Anvin
2004-10-21 5:06 ` Chris Friesen
2004-10-21 5:11 ` H. Peter Anvin
2004-10-21 5:50 ` Chris Friesen
2004-10-21 5:58 ` H. Peter Anvin
2004-10-21 15:18 ` Chris Friesen
2004-10-21 6:14 ` Michael Clark
2004-10-17 14:52 ` Mark Mielke
2004-10-16 18:25 ` Andries Brouwer
2004-10-17 0:28 ` David Schwartz
2004-10-17 12:22 ` Andries Brouwer
2004-10-16 10:24 ` Willy Tarreau
2004-10-16 13:21 ` Mark Mielke
2004-10-18 22:25 ` Robert White
2004-10-06 20:41 ` Neil Horman
2004-10-06 22:27 ` Chris Friesen
2004-10-06 23:32 ` Neil Horman
2004-10-06 23:36 ` David S. Miller
2004-10-07 19:31 ` David Schwartz
2004-10-07 22:36 ` Martijn Sipkema
2004-10-08 0:19 ` David Schwartz
2004-10-09 19:21 ` Martijn Sipkema
2004-10-09 18:28 ` David Schwartz
2004-10-09 18:49 ` Mark Mielke
2004-10-09 21:00 ` Martijn Sipkema
2004-10-09 22:59 ` Mark Mielke
-- strict thread matches above, loose matches on Subject: below --
2004-10-06 15:30 Dan Kegel
2004-10-07 4:50 Dan Kegel
2004-10-07 8:04 ` bert hubert
2004-10-07 8:28 ` Adam Heath
2004-10-07 10:38 ` Martijn Sipkema
2004-10-07 10:07 ` Adam Heath
2004-10-07 11:29 ` Martijn Sipkema
2004-10-07 18:16 linux
2004-10-09 12:07 ` Colin Phipps
[not found] <fa.haprsoi.8k8kbk@ifi.uio.no>
[not found] ` <fa.isqjio8.ok2coo@ifi.uio.no>
2004-10-09 13:24 ` Bodo Eggert
2004-10-19 1:21 John Pearson
2004-10-19 13:50 ` Colin Phipps
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='001c01c4ac76$fb9fd190$161b14ac@boromir' \
--to=msipkema@sipkema-digital.com \
--cc=cfriesen@nortelnetworks.com \
--cc=davem@davemloft.net \
--cc=joris@eljakim.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=paul@clubi.ie \
--cc=root@chaos.analogic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.