All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yang, Sheng" <sheng.yang@intel.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Alex Williamson <alex.williamson@hp.com>,
	Avi Kivity <avi@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 1/1] KVM: Fix potentially recursively get kvm lock
Date: Wed, 13 May 2009 10:07:54 +0800	[thread overview]
Message-ID: <200905131007.55189.sheng.yang@intel.com> (raw)
In-Reply-To: <20090512220908.GA22626@amt.cnet>

On Wednesday 13 May 2009 06:09:08 Marcelo Tosatti wrote:
> On Tue, May 12, 2009 at 03:36:27PM -0600, Alex Williamson wrote:
> > On Tue, 2009-05-12 at 16:44 -0300, Marcelo Tosatti wrote:
> > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > > index 4d00942..ba067db 100644
> > > --- a/virt/kvm/kvm_main.c
> > > +++ b/virt/kvm/kvm_main.c
> > > @@ -250,7 +250,15 @@ static void deassign_host_irq(struct kvm *kvm,
> > >  			disable_irq_nosync(assigned_dev->
> > >  					   host_msix_entries[i].vector);
> > >
> > > +		/*
> > > +		 * FIXME: kvm_assigned_dev_interrupt_work_handler can deadlock
> > > +		 * with cancel_work_sync, since it requires kvm->lock for irq
> > > +		 * injection. This is a hack, the irq code must use
> > > +		 * a separate lock.
> > > +		 */
> > > +		mutex_unlock(&kvm->lock);
> > >  		cancel_work_sync(&assigned_dev->interrupt_work);
> > > +		mutex_lock(&kvm->lock);
> >
> > Seems to work, I assume you've got a similar unlock/lock for the
> > MSI/INTx block.  Thanks,
>
> KVM: workaround workqueue / deassign_host_irq deadlock
>
> I think I'm running into the following deadlock in the kvm kernel module
> when trying to use device assignment:
>
> CPU A                               CPU B
> kvm_vm_ioctl_deassign_dev_irq()
>   mutex_lock(&kvm->lock);           worker_thread()
>   -> kvm_deassign_irq()               ->
> kvm_assigned_dev_interrupt_work_handler()
>     -> deassign_host_irq()              mutex_lock(&kvm->lock);
>       -> cancel_work_sync() [blocked]
>
> Workaround the issue by dropping kvm->lock for cancel_work_sync().
>
> Reported-by: Alex Williamson <alex.williamson@hp.com>
> From: Sheng Yang <sheng.yang@intel.com>
> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>

Another calling path(kvm_free_all_assigned_devices()) don't hold kvm->lock... 
Seems it need the lock for travel assigned dev list?

-- 
regards
Yang, Sheng

> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 4d00942..d4af719 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -250,7 +250,15 @@ static void deassign_host_irq(struct kvm *kvm,
>  			disable_irq_nosync(assigned_dev->
>  					   host_msix_entries[i].vector);
>
> +		/*
> +		 * FIXME: kvm_assigned_dev_interrupt_work_handler can deadlock
> +		 * with cancel_work_sync, since it requires kvm->lock for irq
> +		 * injection. This is a hack, the irq code must use
> +		 * a separate lock. Same below for MSI.
> +		 */
> +		mutex_unlock(&kvm->lock);
>  		cancel_work_sync(&assigned_dev->interrupt_work);
> +		mutex_lock(&kvm->lock);
>
>  		for (i = 0; i < assigned_dev->entries_nr; i++)
>  			free_irq(assigned_dev->host_msix_entries[i].vector,
> @@ -263,7 +271,9 @@ static void deassign_host_irq(struct kvm *kvm,
>  	} else {
>  		/* Deal with MSI and INTx */
>  		disable_irq_nosync(assigned_dev->host_irq);
> +		mutex_unlock(&kvm->lock);
>  		cancel_work_sync(&assigned_dev->interrupt_work);
> +		mutex_lock(&kvm->lock);
>
>  		free_irq(assigned_dev->host_irq, (void *)assigned_dev);



  parent reply	other threads:[~2009-05-13  2:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-12  9:05 device-assignment deadlock Yang, Sheng
2009-05-12  9:32 ` [PATCH 1/1] KVM: Fix potentially recursively get kvm lock Sheng Yang
2009-05-12 11:55   ` Marcelo Tosatti
2009-05-12 14:13     ` Yang, Sheng
2009-05-12 14:30       ` Marcelo Tosatti
2009-05-12 15:59         ` Marcelo Tosatti
2009-05-12 19:44         ` Marcelo Tosatti
2009-05-12 21:36           ` Alex Williamson
2009-05-12 22:09             ` Marcelo Tosatti
2009-05-12 22:17               ` Alex Williamson
2009-05-22 15:06                 ` Chris Wright
2009-05-22 15:34                   ` Alex Williamson
2009-05-22 15:36                     ` Chris Wright
2009-05-13  2:07               ` Yang, Sheng [this message]
2009-05-13 13:14                 ` Marcelo Tosatti
2009-05-13 11:43         ` Gleb Natapov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200905131007.55189.sheng.yang@intel.com \
    --to=sheng.yang@intel.com \
    --cc=alex.williamson@hp.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.