All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Henriques <luis.henriques@canonical.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	saso.linux@astim.si, lists2009@fnarfbargle.com,
	Nadav Amit <namit@cs.technion.ac.il>,
	stable@vger.kernel.org
Subject: Re: [PATCH stable] KVM: x86: Fix lost interrupt on irr_pending race
Date: Wed, 22 Apr 2015 14:34:01 +0100	[thread overview]
Message-ID: <20150422133401.GE3671@charon> (raw)
In-Reply-To: <55360EA9.2030806@redhat.com>

On Tue, Apr 21, 2015 at 10:47:37AM +0200, Paolo Bonzini wrote:
> 
> 
> On 21/04/2015 09:52, Paolo Bonzini wrote:
> > From: Nadav Amit <namit@cs.technion.ac.il>
> > 
> > [ upstream commit f210f7572bedf3320599e8b2d8e8ec2d96270d0b ]
> > 
> > apic_find_highest_irr assumes irr_pending is set if any vector in APIC_IRR is
> > set.  If this assumption is broken and apicv is disabled, the injection of
> > interrupts may be deferred until another interrupt is delivered to the guest.
> > Ultimately, if no other interrupt should be injected to that vCPU, the pending
> > interrupt may be lost.
> > 
> > commit 56cc2406d68c ("KVM: nVMX: fix "acknowledge interrupt on exit" when APICv
> > is in use") changed the behavior of apic_clear_irr so irr_pending is cleared
> > after setting APIC_IRR vector. After this commit, if apic_set_irr and
> > apic_clear_irr run simultaneously, a race may occur, resulting in APIC_IRR
> > vector set, and irr_pending cleared. In the following example, assume a single
> > vector is set in IRR prior to calling apic_clear_irr:
> > 
> > apic_set_irr				apic_clear_irr
> > ------------				--------------
> > apic->irr_pending = true;
> > 					apic_clear_vector(...);
> > 					vec = apic_search_irr(apic);
> > 					// => vec == -1
> > apic_set_vector(...);
> > 					apic->irr_pending = (vec != -1);
> > 					// => apic->irr_pending == false
> > 
> > Nonetheless, it appears the race might even occur prior to this commit:
> > 
> > apic_set_irr				apic_clear_irr
> > ------------				--------------
> > apic->irr_pending = true;
> > 					apic->irr_pending = false;
> > 					apic_clear_vector(...);
> > 					if (apic_search_irr(apic) != -1)
> > 						apic->irr_pending = true;
> > 					// => apic->irr_pending == false
> > apic_set_vector(...);
> > 
> > Fixing this issue by:
> > 1. Restoring the previous behavior of apic_clear_irr: clear irr_pending, call
> >    apic_clear_vector, and then if APIC_IRR is non-zero, set irr_pending.
> > 2. On apic_set_irr: first call apic_set_vector, then set irr_pending.
> > 
> > Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
> > Fixes: 33e4c68656a2e461b296ce714ec322978de85412
> > Cc: stable@vger.kernel.org # 2.6.32+
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > ---
> > 	The race was reported in 3.17+ by Brad Campbell and in
> > 	2.6.32 by Saso Slavicic, so it qualifies for stable.
> 
> Patch for kernels before 3.17:
> 

Thanks Paolo.  I was going to apply this backport to the 3.16 kernel
but it looks like the original commit is a clean cherry-pick.  Shall I
still apply your backport, or do you think the original commit should
be applied instead?

Cheers,
--
Luís

> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 6e8ce5a1a05d..e0e5642dae41 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -341,8 +341,12 @@ EXPORT_SYMBOL_GPL(kvm_apic_update_irr);
>  
>  static inline void apic_set_irr(int vec, struct kvm_lapic *apic)
>  {
> -	apic->irr_pending = true;
>  	apic_set_vector(vec, apic->regs + APIC_IRR);
> +	/*
> +	 * irr_pending must be true if any interrupt is pending; set it after
> +	 * APIC_IRR to avoid race with apic_clear_irr
> +	 */
> +	apic->irr_pending = true;
>  }
>  
>  static inline int apic_search_irr(struct kvm_lapic *apic)
> 
> 
> Thanks,
> 
> Paolo
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Luis Henriques <luis.henriques@canonical.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	saso.linux@astim.si, lists2009@fnarfbargle.com,
	Nadav Amit <namit@cs.technion.ac.il>,
	stable@vger.kernel.org
Subject: Re: [PATCH stable] KVM: x86: Fix lost interrupt on irr_pending race
Date: Wed, 22 Apr 2015 14:34:01 +0100	[thread overview]
Message-ID: <20150422133401.GE3671@charon> (raw)
In-Reply-To: <55360EA9.2030806@redhat.com>

On Tue, Apr 21, 2015 at 10:47:37AM +0200, Paolo Bonzini wrote:
> 
> 
> On 21/04/2015 09:52, Paolo Bonzini wrote:
> > From: Nadav Amit <namit@cs.technion.ac.il>
> > 
> > [ upstream commit f210f7572bedf3320599e8b2d8e8ec2d96270d0b ]
> > 
> > apic_find_highest_irr assumes irr_pending is set if any vector in APIC_IRR is
> > set.  If this assumption is broken and apicv is disabled, the injection of
> > interrupts may be deferred until another interrupt is delivered to the guest.
> > Ultimately, if no other interrupt should be injected to that vCPU, the pending
> > interrupt may be lost.
> > 
> > commit 56cc2406d68c ("KVM: nVMX: fix "acknowledge interrupt on exit" when APICv
> > is in use") changed the behavior of apic_clear_irr so irr_pending is cleared
> > after setting APIC_IRR vector. After this commit, if apic_set_irr and
> > apic_clear_irr run simultaneously, a race may occur, resulting in APIC_IRR
> > vector set, and irr_pending cleared. In the following example, assume a single
> > vector is set in IRR prior to calling apic_clear_irr:
> > 
> > apic_set_irr				apic_clear_irr
> > ------------				--------------
> > apic->irr_pending = true;
> > 					apic_clear_vector(...);
> > 					vec = apic_search_irr(apic);
> > 					// => vec == -1
> > apic_set_vector(...);
> > 					apic->irr_pending = (vec != -1);
> > 					// => apic->irr_pending == false
> > 
> > Nonetheless, it appears the race might even occur prior to this commit:
> > 
> > apic_set_irr				apic_clear_irr
> > ------------				--------------
> > apic->irr_pending = true;
> > 					apic->irr_pending = false;
> > 					apic_clear_vector(...);
> > 					if (apic_search_irr(apic) != -1)
> > 						apic->irr_pending = true;
> > 					// => apic->irr_pending == false
> > apic_set_vector(...);
> > 
> > Fixing this issue by:
> > 1. Restoring the previous behavior of apic_clear_irr: clear irr_pending, call
> >    apic_clear_vector, and then if APIC_IRR is non-zero, set irr_pending.
> > 2. On apic_set_irr: first call apic_set_vector, then set irr_pending.
> > 
> > Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
> > Fixes: 33e4c68656a2e461b296ce714ec322978de85412
> > Cc: stable@vger.kernel.org # 2.6.32+
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > ---
> > 	The race was reported in 3.17+ by Brad Campbell and in
> > 	2.6.32 by Saso Slavicic, so it qualifies for stable.
> 
> Patch for kernels before 3.17:
> 

Thanks Paolo.  I was going to apply this backport to the 3.16 kernel
but it looks like the original commit is a clean cherry-pick.  Shall I
still apply your backport, or do you think the original commit should
be applied instead?

Cheers,
--
Lu�s

> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 6e8ce5a1a05d..e0e5642dae41 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -341,8 +341,12 @@ EXPORT_SYMBOL_GPL(kvm_apic_update_irr);
>  
>  static inline void apic_set_irr(int vec, struct kvm_lapic *apic)
>  {
> -	apic->irr_pending = true;
>  	apic_set_vector(vec, apic->regs + APIC_IRR);
> +	/*
> +	 * irr_pending must be true if any interrupt is pending; set it after
> +	 * APIC_IRR to avoid race with apic_clear_irr
> +	 */
> +	apic->irr_pending = true;
>  }
>  
>  static inline int apic_search_irr(struct kvm_lapic *apic)
> 
> 
> Thanks,
> 
> Paolo
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2015-04-22 13:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1429602745-29882-1-git-send-email-pbonzini@redhat.com>
2015-04-21  8:47 ` [PATCH stable] KVM: x86: Fix lost interrupt on irr_pending race Paolo Bonzini
2015-04-22 13:34   ` Luis Henriques [this message]
2015-04-22 13:34     ` Luis Henriques
2015-04-22 13:47     ` Paolo Bonzini
2015-04-22 13:47       ` Paolo Bonzini
2015-04-22 13:52       ` Luis Henriques
2015-04-22 13:52         ` Luis Henriques
2015-04-28 16:24   ` Saso Slavicic
2015-04-29 16:45     ` Paolo Bonzini

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=20150422133401.GE3671@charon \
    --to=luis.henriques@canonical.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lists2009@fnarfbargle.com \
    --cc=namit@cs.technion.ac.il \
    --cc=pbonzini@redhat.com \
    --cc=saso.linux@astim.si \
    --cc=stable@vger.kernel.org \
    /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.