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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox