[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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.