On Tuesday 30 December 2008 19:16:27 Avi Kivity wrote: > Sheng Yang wrote: > >> This will call cancel_work_sync(), which may wait upon kvm->lock, which > >> I think we hold here -> deadlock. > >> > >> I think that the current code has even bigger problems (races), since a > >> scheduled work can arrive after the interrupt has been freed and > >> reallocated. > > > > For the race problem, how about put a cancel_work_sync() for all devices > > at the beginning of kvm_destroy_vm? Something named > > kvm_arch_cancel_work_sync... > > There is no race at destroy time since the work_struct has a reference > on struct kvm. So destruction is only triggered after the last interrupt. > > (but what if we get another interrupt immediately afterwards?!)
I don't like that reference, I think we can get it done more elegantly... Yes, for MSI, we didn't disable interrupt, so got trouble. So still, how about deal with this at the beginning of kvm_destory_vm? Discard currently reference count. In the function, disable all known interrupt(and result some nested disabled but we would free them later), then cancel_work_sync(). At this time, I think the state is legal(at least workable). -- regards Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
