[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Potential race between shutting down a domain and handling I/O
Hi all,While looking at the I/O handling code, I noticed that hvmemul_do_io() contains the following code: 333 rc = ioreq_send(s, &p, 0); 334 if ( rc != X86EMUL_RETRY || currd->is_shutting_down ) 335 vio->req.state = STATE_IOREQ_NONE;Looking at history [1], it looks like the second part was added to cover the case the I/O was not handled because the domain is shutdown down (i.e. vcpu_start_shutdown_deferral() returned false). However, I think, it would be possible that the request to shutdown happens *after* vcpu_start_shutdown_deferral() returns true. In which case, we would set the state of the I/O to NONE. It is not clear to me what could go wrong, but from the commit message it looks like this wasn't the intended behavior as the I/O would have been sent to the IOREQ. For completeness, I think a similar issue would happen in handle_pio(). We would end up to re-emulate the I/O which may have side-effect (?). Note that the race is tiny and I haven't been able to reproduce it so far. Can someone confirm my understanding? If there are a bug, then I am thinking to extend hvm_vcpu_io to indicate whether the I/O handling was deferred. Any other suggestion? Cheers,[1] https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=0c0cbf72cf9f28070cc5d49955b0a00df5c1d114;hp=d1370961810d3b1630e0ad5e28e5cfc8dcfe2b9b -- Julien Grall
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |