DomainKey-Signature: a=rsa-sha1; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=gJNJvZKP0vEhB3K9N6vYCgk1eAySHHuSNY4wVM3nGg2ujaT5Qo08MFx1XlnM5sNMJp7i4e/+Q+eHKKqSkzpBiJ85x0/Nl2TYaMs22PjbHi4lqzclVWWzF3AAIylZADyjrRogj0nv2AuAeHqiZnhP2J0NYnKpxM4pPN9SloVADG8
Message-ID: <5d6b657504101710542e054f53@mail.gmail.com>
Date: Sun, 17 Oct 2004 19:54:04 +0200
From: Buddy Lucas <buddy.lucas@gmail.com>
Reply-To: Buddy Lucas <buddy.lucas@gmail.com>
To: Lars Marowsky-Bree <lmb@suse.de>
Subject: Re: UDP recvmsg blocks after select(), 2.6 bug?
Cc: David Schwartz <davids@webmaster.com>,
       "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
In-Reply-To: <20041017172244.GM7468@marowsky-bree.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <20041016062512.GA17971@mark.mielke.cc>
	 <MDEHLPKNGKAHNMBLJOLKMEONPAAA.davids@webmaster.com>
	 <20041017133537.GL7468@marowsky-bree.de>
	 <5d6b657504101707175aab0fcb@mail.gmail.com>
	 <20041017172244.GM7468@marowsky-bree.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2881
Lines: 63

On Sun, 17 Oct 2004 19:22:44 +0200, Lars Marowsky-Bree <lmb@suse.de> wrote:
> On 2004-10-17T16:17:06, Buddy Lucas <buddy.lucas@gmail.com> wrote:
> 
> > > The SuV spec is actually quite detailed about the options here:
> > >
> > >         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.)
> > But it says nowhere that the select()/recvmsg() operation is atomic, right?
> 
> See, Buddy, the point here is that Linux _does_ violate the
> specification. You can try weaseling out of it, but it's not going to
> work.

Sigh. Read the quote to which I responded again. Not a word about
atomicity. Nowhere does it say that a descriptor which was ready for
reading at select() time is still readable at recvmsg() time. There is
no doubt that it would be very nice if select() would say something
useful, but that's not the issue here.

> This isn't per se the same as saying that it's not a sensible violation,
> but very clearly the specs disagree with the current Linux behaviour.

So document it.

> It's impossible to claim that you are allowed by the spec to block on a
> recvmsg directly following a successful select. You are not. You could
> claim that, but you'd be wrong.

Empty statement.

> If the packet has been dropped in between, which _could_ have happened
> because UDP is allowed to be dropped basically anywhere, EIO may be
> returned. But blocking or returning EAGAIN/EWOULDBLOCK is verboten. The
> spec is very clearly on that.

Obviously returning EAGAIN/EWOULDBLOCK while reading from a blocking
fd is not what we want (in the situation at hand). I don't see how it
relates to the discussion.

> (Now I'd claim that returning EIO after a succesful select is also
> slightly suboptimal - the performance optimizations should be turned off
> for blocking sockets, IMHO, and the data which caused the select() to
> return should be considered comitted - but it would be allowed.)
> I'm not so sure what's so hard to accept about that. It may be well that
> Linux is following the de-facto industry standard (or even setting it)
> here, and I'd agree that if you don't want blocking use O_NONBLOCK, but
> in no way can Linux claim POSIX/SuV spec compliance for this behaviour.

It doesn't.


Cheers,
Buddy
-
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/