qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH] fix select(2) race between main_loop_wait and qemu_aio_wait
Date: Mon, 05 Mar 2012 17:14:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1

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



reply via email to

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