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: Jan Kiszka
Subject: Re: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s
Date: Tue, 04 Nov 2008 20:08:50 +0100
User-agent: Thunderbird 2.0.0.17 (Windows/20080914)

M. Warner Losh wrote:
> 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?

[ sorting my mind ] What I meant was that some care will likely be taken
to prevent signal delivery _to userspace_ between the unmasking and the
select() call. At least Linux does delivery on syscall return, so should
FreeBSD do. I guess that signals arriving around "/* here */" will
simply prevent select() to block (or even run).

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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