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

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

 



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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux