Re: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s

[Daniel P. Berrange]

On Wed, Nov 05, 2008 at 09:16:59PM +0100, andrzej zaborowski wrote:
> 2008/11/5 Jan Kiszka <address@hidden>:
> > M. Warner Losh wrote:
> >> In message: <address@hidden>
> >>             Jamie Lokier <address@hidden> 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 :|