From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KxooJ-0004rg-Vp for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:17:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KxooI-0004qo-3V for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:17:03 -0500 Received: from [199.232.76.173] (port=55261 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KxooI-0004ql-0m for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:17:02 -0500 Received: from rv-out-0708.google.com ([209.85.198.242]:61200) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KxooH-00072a-Nr for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:17:02 -0500 Received: by rv-out-0708.google.com with SMTP id f25so173386rvb.22 for ; Wed, 05 Nov 2008 12:17:00 -0800 (PST) Message-ID: Date: Wed, 5 Nov 2008 21:16:59 +0100 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s In-Reply-To: <4911E434.5020105@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081104113204.GA32125@shareable.org> <20081104.092231.-1384053398.imp@bsdimp.com> <20081105150042.GJ13630@shareable.org> <20081105.091015.232928302.imp@bsdimp.com> <4911E434.5020105@web.de> 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 2008/11/5 Jan Kiszka : > M. Warner Losh wrote: >> In message: <20081105150042.GJ13630@shareable.org> >> Jamie Lokier writes: >> : M. Warner Losh wrote: >> : > : In other words, don't use pselect() if you might run on a kernel older >> : > : than 2.6.16, or on a host architecture which adds pselect() in a later >> : > : kernel version. Also, I wouldn't be surprised if older versions of >> : > : some BSDs have similar dodgy wrappers. >> : > >> : > Which ones have a good kernel implementation of it? FreeBSD's is >> : > currently approximately: >> : > >> : > if (!mask) >> : > _sigprocmask(mask, &oldmask); >> : > /* here */ >> : > select(); >> : > if (!mask) >> : > _sigprocmask(oldmask, NULL); >> : > >> : > I'm assuming that the problem is due to a signal arriving at /* here */. >> : >> : If that's _kernel_ code and the kernel behaves like Linux, it's not a >> : problem because signals don't affect the control flow until returning >> : to userspace, meaning the select() will return EINTR. >> >> It is currently user level code, and I'm looking at moving it into the >> kernel, but I need to understand the race being talked about here. > > From the Linux man page on [p]select: > > "The reason that pselect() is needed is that if one wants to wait for > either a signal or for a file descriptor to become ready, then an atomic > test is needed to prevent race conditions. (Suppose the signal handler > sets a global flag and returns. Then a test of this global flag followed > by a call of select() could hang indefinitely if the signal arrived just > after the test but just before the call. By contrast, pselect() allows > one to first block signals, handle the signals that have come in, then > call pselect() with the desired sigmask, avoiding the race.)" > > So the unmasking and possible blocking on select must be done > atomically. And that is only feasible in kernel land. To be exact, it *was* possible for glibc to implement a pselect free of races: that is by using the same trick as your patch, i.e. making a pipe and adding it to select()ed fd's and mangling the sigmask. Cheers