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

[Jamie Lokier <jamie@shareable.org>]

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

Ugh, I had imagined FreeBSD would have got that right, since it's
quite good in other areas.  I've added FreeBSD to my blacklist of
broken pselect() implementations, thanks for the info.

Do you know if FreeBSD's pread() and pwrite() are also thread-unsafe
userspace wrappers using lseek+read/write?  They are harder to avoid
when you're looking at high performance code.

> Why is it no good.  What is the race here?  Is it just the oldmask
> thing and multiple callers to select, or is it something else?

It's racy with a single caller.  The race is: program's signal handler
sets a flag like "alarm_happened = 1".  The program's main loop checks
the flag before calling select().  If the signal is delivered before
that check, the program doesn't call select() and handles the reason
for the flag.  If the signal is delivered during select(), that
returns EINTR and the program handles the reason for the flag.  But if
the signal is delivered _between_ checking the flag and calling
select(), the program gets stuck.

pselect() avoids that stuck state, by blocking the signal before the
program checks the flag, and guaranteeing if the signal is delivered
after that point, pselect() returns EINTR.  It's sort of analogous to
pthread_cond_wait() needing a mutex.

> And if it is the oldmask thing, why wouldn't multiple callers of
> pselect mess it up depending on what order they have.

Signal masks are per-thread anyway, multiple callers isn't an issue.

-- Jamie