From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kxozr-0000eI-5z for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:28:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kxozp-0000d4-4u for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:28:58 -0500 Received: from [199.232.76.173] (port=58644 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kxozo-0000cz-RG for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:28:56 -0500 Received: from mx1.redhat.com ([66.187.233.31]:39629) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kxozo-0001Yl-AU for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:28:56 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id mA5KSr6Z014760 for ; Wed, 5 Nov 2008 15:28:53 -0500 Received: from file.fab.redhat.com (file.fab.redhat.com [10.33.63.6]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mA5KSq8r024290 for ; Wed, 5 Nov 2008 15:28:52 -0500 Received: from file.fab.redhat.com (localhost.localdomain [127.0.0.1]) by file.fab.redhat.com (8.13.1/8.13.1) with ESMTP id mA5KSqhG016261 for ; Wed, 5 Nov 2008 20:28:52 GMT Received: (from berrange@localhost) by file.fab.redhat.com (8.13.1/8.13.1/Submit) id mA5KSqU8016257 for qemu-devel@nongnu.org; Wed, 5 Nov 2008 20:28:52 GMT Date: Wed, 5 Nov 2008 20:28:52 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s Message-ID: <20081105202852.GZ25523@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Reply-To: "Daniel P. Berrange" , 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 On Wed, Nov 05, 2008 at 09:16:59PM +0100, andrzej zaborowski wrote: > 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. Yes & no. The trouble with glibc using pipes behind your back is that then it creates a totally different race in threaded apps, where a FD could be leaked to a child process between glibc opening its secret pipe and setting the O_CLOSEXEC flag. Indeed it already suffers from this problem with name resolving Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|