All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Chuck Anderson <chuck.anderson@oracle.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@novell.com>
Subject: Re: 2.6.32 PV Xen donU guest panic on nested call to arch_enter_lazy_mmu_mode()
Date: Wed, 08 Dec 2010 14:28:51 -0800	[thread overview]
Message-ID: <4D0006A3.8010307@goop.org> (raw)
In-Reply-To: <4CFED74D.1040304@oracle.com>

On 12/07/2010 04:54 PM, Chuck Anderson wrote:
> The easy fix is to disable interrupts in copy_pte_range() before
> calling arch_enter_lazy_mmu_mode() and re-enable them after the call
> to arch_leave_lazy_mmu_mode() but I'm asking if there is a better way
> to handle this.  If disabling interrupts is best, there are other
> calls to arch_enter_lazy_mmu_mode() that appear to have the same
> interruption issue.  It may be best then to disable interrupts in
> arch_enter_lazy_mmu_mode() or paravirt_enter_lazy_mmu().

Disabling interrupts would cause too much latency.  I think we may have
done this at one point, but it is very antisocial.

Since lazy mode is effectively disabled in interrupt handlers anyway, it
should just be enough to ignore enter/leave requests.  Does this work
for you?

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Date: Wed, 8 Dec 2010 14:21:16 -0800
Subject: [PATCH] x86/paravirt: don't enter/leave lazy mode in interrupts.

We already ignore the current state of lazy mode in interrupts, but we
should also ignore any attempt to enter/leave lazy mode within
an interrupt context.

enter_lazy() will BUG if it sees an attempt at a nested entry to lazy
mode, which is generally an error.  However, it's possible that an
interrupt handler may do something that would trigger a batched MMU
update, for example, and that could interrupt an existing batched update.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reported-by: Chuck Anderson <chuck.anderson@oracle.com>
Cc: Jan Beulich <JBeulich@novell.com>
Cc: Stable Kernel <stable@kernel.org>

diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index c5b2500..a2ad10d 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -231,6 +231,9 @@ static DEFINE_PER_CPU(enum paravirt_lazy_mode, paravirt_lazy_mode) = PARAVIRT_LA
 
 static inline void enter_lazy(enum paravirt_lazy_mode mode)
 {
+	if (in_interrupt())
+		return;
+
 	BUG_ON(percpu_read(paravirt_lazy_mode) != PARAVIRT_LAZY_NONE);
 
 	percpu_write(paravirt_lazy_mode, mode);
@@ -238,6 +241,9 @@ static inline void enter_lazy(enum paravirt_lazy_mode mode)
 
 static void leave_lazy(enum paravirt_lazy_mode mode)
 {
+	if (in_interrupt())
+		return;
+
 	BUG_ON(percpu_read(paravirt_lazy_mode) != mode);
 
 	percpu_write(paravirt_lazy_mode, PARAVIRT_LAZY_NONE);


Thanks,
	J

  parent reply	other threads:[~2010-12-08 22:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-08  0:54 2.6.32 PV Xen donU guest panic on nested call to arch_enter_lazy_mmu_mode() Chuck Anderson
2010-12-08  8:48 ` Jan Beulich
2010-12-08 21:21   ` Jeremy Fitzhardinge
2010-12-08 22:28 ` Jeremy Fitzhardinge [this message]
2010-12-09  1:21   ` Chuck Anderson
2010-12-09  6:50     ` Chuck Anderson
2010-12-09 17:43     ` Jeremy Fitzhardinge

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=4D0006A3.8010307@goop.org \
    --to=jeremy@goop.org \
    --cc=JBeulich@novell.com \
    --cc=chuck.anderson@oracle.com \
    --cc=xen-devel@lists.xensource.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.