Re: 2.6.32 PV Xen donU guest panic on nested call to arch_enter_lazy_mmu_mode()

[Chuck Anderson <chuck.anderson@oracle.com>]

Jeremy,
  Looking at copy_pte_range(), the stale update scenario I described 
below can't happen.  I believe the deadlock could happen but that is not 
a lazy/not lazy MMU update issue.

Here is an extract from your proposed patch:

 static inline void enter_lazy(enum paravirt_lazy_mode mode)
 {
+    if (in_interrupt())
+        return;
+
     BUG_ON(percpu_read(paravirt_lazy_mode) != PARAVIRT_LAZY_NONE);

My vote is for something like:

 static inline void enter_lazy(enum paravirt_lazy_mode mode)
 {
-       BUG_ON(percpu_read(paravirt_lazy_mode) != PARAVIRT_LAZY_NONE);
+       /*
+        * Switch modes only if we are not in an interrupt context.
+        * The mode is ignored while handling an interrupt.
+        */
+       if (!in_interrupt()) {
+               BUG_ON(percpu_read(paravirt_lazy_mode) != 
PARAVIRT_LAZY_NONE);

-       percpu_write(paravirt_lazy_mode, mode);
+               percpu_write(paravirt_lazy_mode, mode);
+       }
 }

 static void leave_lazy(enum paravirt_lazy_mode mode)
 {
-        BUG_ON(percpu_read(paravirt_lazy_mode) != mode);
+      /*
+       * Switch modes only if we are not in an interrupt context.
+       * The mode is ignored while handling an interrupt.
+       */
+      if (!in_interrupt()) {
+              BUG_ON(percpu_read(paravirt_lazy_mode) != mode);
 
-        percpu_write(paravirt_lazy_mode, PARAVIRT_LAZY_NONE);
+              percpu_write(paravirt_lazy_mode, PARAVIRT_LAZY_NONE);
+       }
 }

Thanks,
Chuck

Chuck Anderson wrote:
> Jeremy,
>  Is it possible for an ongoing lazy mode update to have batched some 
> MMU updates; an interrupt occurs; an interrupt routine does a non-lazy 
> MMU update for a PTE that is also in the lazy update queue; that 
> update is overwritten on return from the interrupt when the update 
> queue is flushed?  Or are the PTE updates protected by a lock?  If 
> they are, wouldn't we deadlock in the interrupt routine when it tries 
> to obtain that (I assume) spinlock?
> Chuck