From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L00DK-0007Pc-R3 for qemu-devel@nongnu.org; Tue, 11 Nov 2008 15:51:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L00DG-0007MS-W0 for qemu-devel@nongnu.org; Tue, 11 Nov 2008 15:51:54 -0500 Received: from [199.232.76.173] (port=38058 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L00DG-0007ME-LC for qemu-devel@nongnu.org; Tue, 11 Nov 2008 15:51:50 -0500 Received: from mx2.redhat.com ([66.187.237.31]:48597) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L00DG-0005MB-Bv for qemu-devel@nongnu.org; Tue, 11 Nov 2008 15:51:50 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mABKpmU2011937 for ; Tue, 11 Nov 2008 15:51:49 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mABKpmlQ014311 for ; Tue, 11 Nov 2008 15:51:48 -0500 Received: from zweiblum.travel.kraxel.org (vpn-4-149.str.redhat.com [10.32.4.149]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mABKpkAp004332 for ; Tue, 11 Nov 2008 15:51:47 -0500 Message-ID: <4919F062.2070504@redhat.com> Date: Tue, 11 Nov 2008 21:51:46 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [patch] Fix block I/O hang. References: <4919B46C.3040804@redhat.com> <4919B79A.5030402@codemonkey.ws> <4919C550.5020609@redhat.com> <4919C71E.2030509@codemonkey.ws> In-Reply-To: <4919C71E.2030509@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Anthony Liguori wrote: > Yes, this all is. I think the intention was to make it non-blocking so > that the full queue could be drained to avoid superfluous calls to > posix_aio_read() since it handles all outstanding ops at once. That is what I concluded after a brief look, without realizing that the loop doesn't actually do that (yet?), thus went for the "oops, this fd must be in non-blocking mode" fix. > However, > >> 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 think it would be good to root cause this. AFAICT, it shouldn't block. Yes, something is fishy here. Will try to pin it. Ideas where to look are welcome in case you have any ;) cheers, Gerd