Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S269285AbUJQULh (ORCPT ); Sun, 17 Oct 2004 16:11:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S269260AbUJQULd (ORCPT ); Sun, 17 Oct 2004 16:11:33 -0400 Received: from gate.in-addr.de ([212.8.193.158]:42978 "EHLO mx.in-addr.de") by vger.kernel.org with ESMTP id S269289AbUJQULb (ORCPT ); Sun, 17 Oct 2004 16:11:31 -0400 Date: Sun, 17 Oct 2004 22:08:04 +0200 From: Lars Marowsky-Bree To: Martijn Sipkema , Buddy Lucas , Jesper Juhl Cc: David Schwartz , "Linux-Kernel@Vger. Kernel. Org" Subject: Re: UDP recvmsg blocks after select(), 2.6 bug? Message-ID: <20041017200804.GP7468@marowsky-bree.de> References: <20041016062512.GA17971@mark.mielke.cc> <20041017133537.GL7468@marowsky-bree.de> <5d6b657504101707175aab0fcb@mail.gmail.com> <20041017150509.GC10280@mark.mielke.cc> <5d6b65750410170840c80c314@mail.gmail.com> <5d6b65750410171104320bc6a8@mail.gmail.com> <20041017180629.GO7468@marowsky-bree.de> <003001c4b484$8999fe70$161b14ac@boromir> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <003001c4b484$8999fe70$161b14ac@boromir> X-Ctuhulu: HASTUR User-Agent: Mutt/1.5.6i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1639 Lines: 42 On 2004-10-17T21:04:40, Martijn Sipkema wrote: > > The specs don't disagree with that. On a O_NONBLOCK socket, that is > > allowed. > No, it isn't. select() may not behave differently based on the O_NONBLOCK > flag at the moment of the select() call. Yes it may. Though this is getting nitpicking; please re-read: "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.)" No claim is made for O_NONBLOCK set; so in that case we can do something sane. > And if a call to recvmsg() with O_NONBLOCK cleared doesn't block and > since it can't return EAGAIN, then I don't think a recvmsg() call with > O_NONBLOCK set should return EAGAIN where something like EIO should > have been returned otherwise. Point taken. For UDP, returning EIO in both cases is just fine (it's actually also correct, for a checksum error constitutes a "network read error"...). At least according to the spec. Sincerely, Lars Marowsky-Br?e -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX AG - A Novell company - 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/