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

[Avi Kivity <avi@redhat.com>]

On 03/05/2012 06:14 PM, Paolo Bonzini wrote:
> Il 05/03/2012 16:14, Avi Kivity ha scritto:
> >> > 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).
>
> Yes, that could work, but it is _really_ ugly. 

Yes, it is...

>  I still prefer this
> patch or fixing NBD.  At least both contain the hack in a single place.



> >> > 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.
>
> That would open another Pandora's box.  The point of having a separate
> main loop is that only AIO can happen during qemu_aio_wait() or
> qemu_aio_flush().  In particular you don't want the monitor to process
> input while you're running another monitor command.

Hmm, yes, we're abusing the type of completion here as a kind of wierd
locking.  It's conceptually broken since an aio completion could trigger
anything.  Usually it just involves block format driver and device code,
but in theory, it can affect the state of whoever's running qemu_aio_wait().

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