From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KxHIJ-0003Qd-IN for qemu-devel@nongnu.org; Tue, 04 Nov 2008 03:29:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KxHIH-0003QR-HX for qemu-devel@nongnu.org; Tue, 04 Nov 2008 03:29:46 -0500 Received: from [199.232.76.173] (port=39223 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KxHIH-0003QO-8y for qemu-devel@nongnu.org; Tue, 04 Nov 2008 03:29:45 -0500 Received: from mx20.gnu.org ([199.232.41.8]:53215) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KxHIH-0005ka-5H for qemu-devel@nongnu.org; Tue, 04 Nov 2008 03:29:45 -0500 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KxHIF-0004U6-Bs for qemu-devel@nongnu.org; Tue, 04 Nov 2008 03:29:43 -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 mA48TebE017030 for ; Tue, 4 Nov 2008 03:29:40 -0500 Message-ID: <491007FD.3020704@redhat.com> Date: Tue, 04 Nov 2008 10:29:49 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s References: <490B53F0.9040200@codemonkey.ws> <490DFAA2.7040900@web.de> <490F5942.6020100@codemonkey.ws> <490F60E4.1040304@web.de> <490F723E.7070308@web.de> In-Reply-To: <490F723E.7070308@web.de> Content-Type: text/plain; charset=UTF-8; format=flowed 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 Jan Kiszka wrote: > There is a race between the alarm_timer firing SIGALRM and > main_loop_wait reaching the safe harbor of select (with that infamous 5 > second timeout). If the signal comes when already blocked in select, it > will properly resume the latter immediately. But if the timer fired > BEFORE that point, host_alarm_handler will only set a flag that the host > timer has fired, the actual rearming will be done AFTER return from > select. Ooops.... > > So, select should actually include the host timer as event. timerfd? > Unfortunately a recent Linux-only feature :-/. I don't think we can > rearm the timer from within the signal handler, at least not without > running all the pending qemu timers. And that is surely not a signal > handler job (qemu timer handler aren't thread-safe in general). > > Anyone any ideas? /me is thinking a bit more about it as well. > pselect(): 1. run tcg code 2. block signals 3. pselect (enabling signals) 4. process pselect results (signals disabled again) 5. unblock signals 6. goto 1 Prior to Linux 2.6.16, pselect() was racy since it was implemented in userspace rather than the kernel. I don't think it's a problem now. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.