Re: [RFC PATCH] fix select(2) race between main_loop_wait and qemu_aio_wait

[Avi Kivity <avi@redhat.com>]

On 03/05/2012 04:30 PM, Paolo Bonzini wrote:
> Il 05/03/2012 15:24, Avi Kivity ha scritto:
> > On 03/05/2012 11:07 AM, Jan Kiszka wrote:
> >> On 2012-03-05 09:34, Paolo Bonzini wrote:
> >>> This is quite ugly.  Two threads, one running main_loop_wait and
> >>> one running qemu_aio_wait, can race with each other on running the
> >>> same iohandler.  The result is that an iohandler could run while the
> >>> underlying socket is not readable or writable, with possibly ill effects.
> >>
> >> Hmm, isn't it a problem already that a socket is polled by two threads
> >> at the same time? Can't that be avoided?
> > 
> > Could it be done simply by adding a mutex there?  It's hardly a clean
> > fix, but it's not a clean problem.
>
> Hmm, I don't think so.  It would need to protect execution of the
> iohandlers too, and pretty much everything can happen there including a
> nested loop.  Of course recursive mutexes exist, but it sounds like too
> big an axe.

The I/O handlers would still use the qemu mutex, no?  we'd just protect
the select() (taking the mutex from before releasing the global lock,
and reacquiring it afterwards).

> I could add a generation count updated by qemu_aio_wait(), and rerun the
> select() only if the generation count changes during its execution.
>
> Or we can call it an NBD bug.  I'm not against that, but it seemed to me
> that the problem is more general.

What about making sure all callers of qemu_aio_wait() run from
coroutines (or threads)?  Then they just ask the main thread to wake
them up, instead of dispatching completions themselves.

-- 
error compiling committee.c: too many arguments to function