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

[Paolo Bonzini <pbonzini@redhat.com>]

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.  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.

Paolo