Re: KVM Guest mmap.c bug

[Bruno Cesar Ribas <ribas@c3sl.ufpr.br>]

On Mon, Mar 08, 2010 at 03:49:01PM +0100, Andrea Arcangeli wrote:
> On Mon, Mar 08, 2010 at 03:32:19PM +0200, Avi Kivity wrote:
> > It looks unrelated to kvm, though of course random memory corruption 
> > cannot be ruled out.
> > 
> > Is npt enabled on the host (cat /sys/module/kvm_amd/parameters/npt)?
> > 
> > Andrea, any idea?
> 
> Basically find_vma(vma->vm_mm, vma->vm_start) doesn't return "vma"
> despite "vma" is the one with the smaller vm_end where the comparison
> "vma->vm_start < vma->vm_end" is true (the next vma is null and the
> prev will have vma->vm_start == prev->vm_end, not <).
> 
> The bug check looks right, it doesn't seem false positive and this
> bugcheck indicates that the vma rbtree is memory-corrupted somehow.
> 
> so yes fiddling with npt on and off sounds a good start, if it's a bug

I can confirm it happens with npt on and off.

And it also happens on a Nehalem XEON (it just happened).

> in shadow paging it's unlikely the exact same bug materializes with
> both npt and without. If the crash happens with npt on and off, then
> maybe it's not hypervisor related. Could also be bad RAM if it only

I doubt it is bad ram! This machine is working (wihtout KVM) for almost 2
years and MCE does not report any problems on the host machine.

And it happens on two identical machines (Opteron) and now o the new (5 days
old) Intel Nehalem XEON.

All guest are Running the same kernel. It happens with a kernel compiled by
me and from debian SID both 2.6.32.9, and from previous kernel I tried
(2.6.31.12 and 2.6.27.45)

> happens on a single host and all other hosts are fine with same binary
> guest/host kernels (rbtree walk might stress the memory bus more than
> other operations). Said that vm_next being null (and if it's null,
> likely vm_next pointer has no ram bitflip) is a bit weird and not
> common scenario and this page fault seems triggered with procfs
> copy_user call which is non standard, so maybe this is a guest bug. It
> would be interesting to know what is the vm_start address, at the end
> there are stack, vdso and vsyscall areas.

I'll make it print vm_start for next reboot.

-- 
Bruno Ribas - ribas@c3sl.ufpr.br
http://www.inf.ufpr.br/ribas
C3SL: http://www.c3sl.ufpr.br