From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L0G5r-0006Wr-CQ for qemu-devel@nongnu.org; Wed, 12 Nov 2008 08:49:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L0G5q-0006Wb-3K for qemu-devel@nongnu.org; Wed, 12 Nov 2008 08:49:14 -0500 Received: from [199.232.76.173] (port=40968 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L0G5q-0006WY-1L for qemu-devel@nongnu.org; Wed, 12 Nov 2008 08:49:14 -0500 Received: from bar.sig21.net ([88.198.146.85]:34842) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L0G5p-00058G-Hk for qemu-devel@nongnu.org; Wed, 12 Nov 2008 08:49:13 -0500 Received: from p54be97c2.dip0.t-ipconnect.de ([84.190.151.194] helo=void.local) by bar.sig21.net with esmtpsa (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.63) (envelope-from ) id 1L0G5e-0005l6-Ju for qemu-devel@nongnu.org; Wed, 12 Nov 2008 14:49:04 +0100 Received: from js by void.local with local (Exim 4.69) (envelope-from ) id 1L0G5e-000146-8i for qemu-devel@nongnu.org; Wed, 12 Nov 2008 14:49:02 +0100 Date: Wed, 12 Nov 2008 14:49:02 +0100 From: Johannes Stezenbach Subject: Re: [Qemu-devel] [patch] Fix block I/O hang. Message-ID: <20081112134902.GA4014@linuxtv.org> References: <4919B46C.3040804@redhat.com> <4919B79A.5030402@codemonkey.ws> <4919C550.5020609@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4919C550.5020609@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, On Tue, Nov 11, 2008 at 06:48:00PM +0100, Gerd Hoffmann wrote: > Anthony Liguori wrote: > > > > Under what circumstances? posix_aio_read() is only invoked from a > > select callback. This means there should be data available to be read. ... > > Third, when called from a select callback it shouldn't block indeed. It > does though for me now and then when booting xen guests (with a big > stack of xenner patches). Doesn't reproduce reliable though. Sprinkled > in a printk (with rfd being non-blocking) and got a EAGAIN once, so it > got called with rfd not having data. I don't know what kind of fd you're talking about, but the Linux select man page says: BUGS Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a sub‐ sequent read blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded. There may be other circumstances in which a file descriptor is spuriously reported as ready. Thus it may be safer to use O_NONBLOCK on sockets that should not block. HTH Johannes