> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Wednesday, May 11, 2011 5:44 PM
> 
> On Wed, 2011-05-11 at 02:20 +0100, Tian, Kevin wrote:
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > Sent: Wednesday, May 11, 2011 4:27 AM
> > >
> > > On Fri, Apr 29, 2011 at 12:10:57PM +0800, Tian, Kevin wrote:
> > > >     xen mmu: fix a race window causing leave_mm BUG()
> > >
> > > I've this in mailbox and I am wondering whether this still an issue
> > > with the
> > > 2.6.39 type kernels?
> > > How do you reproduce the failure? When using LVM?
> >
> > this issue is reported by Xiaoyun when he did extensive test which
> > happened occasionally after dozen of hours running. From the
> > phenomenon and info provided by Xiaoyun, I found this potential race
> > window and Xiaoyun has verified this patch solving his stability issue.
> >
> > the original thread is at:
> > http://lists.xensource.com/archives/html/xen-devel/2011-04/msg01186.ht
> > ml
> >
> > his kernel is based on 2.6.38, and I checked latest 2.6.39 from your
> > maintained repo, and same issue still exists.
> >
> > btw, I didn't reproduce it myself, and not sure whether Xiaoyun uses
> > LVM. But I think it has nothing to do with storage type, and a pure mmu
> design issue.
> 
> Is there a specific stack trace (or two) which is associated with this bug? I'm
> wondering if http://bugs.debian.org/613073 might be the same thing...
> 

If you look into above thread:

http://lists.xensource.com/archives/html/xen-devel/2011-04/msg00657.html

[<ffffffff8100e4a4>] drop_other_mm_ref+0x2a/0x53

 [<ffffffff81087224>] generic_smp_call_function_single_interrupt+0xd8/0xfc

 [<ffffffff810100e8>] xen_call_function_single_interrupt+0x13/0x28

 [<ffffffff810a936a>] handle_IRQ_event+0x66/0x120

 [<ffffffff810aac5b>] handle_percpu_irq+0x41/0x6e

 [<ffffffff8128c1a8>] __xen_evtchn_do_upcall+0x1ab/0x27d

 [<ffffffff8128dcf9>] xen_evtchn_do_upcall+0x33/0x46

 [<ffffffff81013efe>] xen_do_hypervisor_callback+0x1e/0x30

...

Thanks
Kevin