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