From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 2/3] KVM: Use kvm_free_assigned_irq() for free irq Date: Tue, 30 Dec 2008 19:22:51 +0800 Message-ID: <200812301922.51604.sheng@linux.intel.com> References: <1230616173-17723-1-git-send-email-sheng@linux.intel.com> <200812301911.10975.sheng@linux.intel.com> <495A030B.1040302@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mga10.intel.com ([192.55.52.92]:36618 "EHLO fmsmga102.fm.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751566AbYL3LWy (ORCPT ); Tue, 30 Dec 2008 06:22:54 -0500 In-Reply-To: <495A030B.1040302@redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: 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