qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: M. Warner Losh
Subject: Re: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s
Date: Tue, 04 Nov 2008 10:55:33 -0700 (MST)

In message: <address@hidden>
            Jan Kiszka <address@hidden> writes:
: M. Warner Losh wrote:
: > In message: <address@hidden>
: >             Jamie Lokier <address@hidden> writes:
: > : andrzej zaborowski wrote:
: > : > > My man page even warns that the Linux
: > : > > kernel is not implementing it yet, though I don't think this still
: > : > > applies to recent 2.6.2x kernels.
: > : > 
: > : > According to the man page it moved to kernel at 2.6.16 but the glibc
: > : > wrapper should be ok too.
: > : 
: > : If there's a glibc wrapper, it cannot be reliable...
: > : 
: > : *Looks at glibc source*
: > : 
: > : That's right.  The glibc pselect() wrapper has the same race condition
: > : which prompted this QEMU bug.  If the signal arrives after unmasking
: > : and before select() in the wrapper, then blocks.
: > : 
: > : 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 */.
: 
: I guess those things happen under some kind of preemption lock,
: otherwise it would be a really poor implementation.

Why?  There's races there anyway.  IF you have a mutex to prevent
multiple calls, doesn't that serialize calls to select?

Warner




reply via email to

[Prev in Thread] Current Thread [Next in Thread]