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

["M. Warner Losh" <imp@bsdimp.com>]

In message: <491081EB.5070905@web.de>
            Jan Kiszka <jan.kiszka@web.de> writes:
: M. Warner Losh wrote:
: > In message: <20081104113204.GA32125@shareable.org>
: >             Jamie Lokier <jamie@shareable.org> 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