* Kernel oops in host caused by mmaping RAM @ 2011-04-12 19:41 Sasha Levin 2011-04-12 21:09 ` Jan Kiszka 2011-04-12 23:27 ` [PATCH] KVM: VMX: Ensure that vmx_create_vcpu always returns proper error Jan Kiszka 0 siblings, 2 replies; 6+ messages in thread From: Sasha Levin @ 2011-04-12 19:41 UTC (permalink / raw) To: kvm Hello, I've tried using mmap to map the RAM of a guest instead of posix_memalign which is used both in the kvm tool and qemu. Doing so caused a kernel Oops, which happens every time I run the code and was confirmed both on 2.6.38 and the latest git build of 2.6.39. [32109.368018] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [32109.368018] IP: [<ffffffff810033b0>] kvm_vm_ioctl+0xbc/0x33a [32109.368018] PGD d7202067 PUD 6a838067 PMD 0 [32109.368018] Oops: 0002 [#1] PREEMPT SMP [32109.368018] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host2/target2:0:0/2:0:0:0/block/sda/uevent [32109.368018] CPU 0 [32109.368018] Modules linked in: [32109.368018] [32109.368018] Pid: 20829, comm: kvm Not tainted 2.6.38-gentoo-r1 #4 System manufacturer System Product Name/P5GC-MX/1333 [32109.368018] RIP: 0010:[<ffffffff810033b0>] [<ffffffff810033b0>] kvm_vm_ioctl+0xbc/0x33a [32109.368018] RSP: 0018:ffff880037013e28 EFLAGS: 00010207 [32109.368018] RAX: 0000000000000000 RBX: ffff880037158000 RCX: 0000000000000000 [32109.368018] RDX: 0000000000000000 RSI: ffff880037013d78 RDI: 0000000000000206 [32109.368018] RBP: ffff880037013ea8 R08: ffff880000098e00 R09: 0000000000000004 [32109.368018] R10: 0000000000000000 R11: ffff880037013ca8 R12: 0000000000000000 [32109.368018] R13: 000000000000ae41 R14: 0000000000000000 R15: 0000000000000000 [32109.368018] FS: 00007f83f7cd9700(0000) GS:ffff8800d7c00000(0000) knlGS:0000000000000000 [32109.368018] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [32109.368018] CR2: 0000000000000008 CR3: 00000000d062e000 CR4: 00000000000026e0 [32109.368018] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [32109.368018] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [32109.368018] Process kvm (pid: 20829, threadinfo ffff880037012000, task ffff88008525d340) [32109.368018] Stack: [32109.368018] ffff880037013e48 ffffffff8150d59c ffff88000e9b9308 ffff88000e9b9308 [32109.368018] ffff880037013ec8 ffffffff81079e25 ffff8800d7c0e388 ffff88000e9b9308 [32109.368018] 0000000000000001 000000000000e380 ffff880037013e98 ffffffff8105b04e [32109.368018] Call Trace: [32109.368018] [<ffffffff8150d59c>] ? _raw_spin_unlock_irqrestore+0x3c/0x49 [32109.368018] [<ffffffff81079e25>] ? __hrtimer_start_range_ns+0x2b4/0x2c6 [32109.368018] [<ffffffff8105b04e>] ? get_parent_ip+0x11/0x41 [32109.368018] [<ffffffff810f1ba9>] do_vfs_ioctl+0x3f1/0x440 [32109.368018] [<ffffffff8150d59c>] ? _raw_spin_unlock_irqrestore+0x3c/0x49 [32109.368018] [<ffffffff8107605c>] ? sys_timer_settime+0x254/0x2a4 [32109.368018] [<ffffffff810f1c49>] sys_ioctl+0x51/0x74 [32109.368018] [<ffffffff81027a52>] system_call_fastpath+0x16/0x1b [32109.368018] Code: 40 40 0f 85 70 02 00 00 e9 13 02 00 00 44 89 e6 45 89 e6 48 89 df e8 19 6e 00 00 49 89 c4 49 81 fc 00 f0 ff ff 0f 87 6f 02 00 00 <49> c7 44 24 08 00 00 00 00 49 c7 44 24 10 00 00 00 00 49 c7 44 [32109.368018] RIP [<ffffffff810033b0>] kvm_vm_ioctl+0xbc/0x33a [32109.368018] RSP <ffff880037013e28> [32109.368018] CR2: 0000000000000008 [32109.368018] [drm] force priority to high [32109.385714] ---[ end trace 0fc207e73803c472 ]--- -- Sasha. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kernel oops in host caused by mmaping RAM 2011-04-12 19:41 Kernel oops in host caused by mmaping RAM Sasha Levin @ 2011-04-12 21:09 ` Jan Kiszka 2011-04-13 12:50 ` Pekka Enberg 2011-04-12 23:27 ` [PATCH] KVM: VMX: Ensure that vmx_create_vcpu always returns proper error Jan Kiszka 1 sibling, 1 reply; 6+ messages in thread From: Jan Kiszka @ 2011-04-12 21:09 UTC (permalink / raw) To: Sasha Levin; +Cc: kvm [-- Attachment #1: Type: text/plain, Size: 454 bytes --] On 2011-04-12 21:41, Sasha Levin wrote: > Hello, > > I've tried using mmap to map the RAM of a guest instead of > posix_memalign which is used both in the kvm tool and qemu. > > Doing so caused a kernel Oops, which happens every time I run the code > and was confirmed both on 2.6.38 and the latest git build of 2.6.39. > Can you share the test case that triggers it? That's easier than guessing what you did precisely. Thanks, Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 259 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kernel oops in host caused by mmaping RAM 2011-04-12 21:09 ` Jan Kiszka @ 2011-04-13 12:50 ` Pekka Enberg 2011-04-13 12:58 ` Sasha Levin 0 siblings, 1 reply; 6+ messages in thread From: Pekka Enberg @ 2011-04-13 12:50 UTC (permalink / raw) To: Jan Kiszka; +Cc: Sasha Levin, kvm On Wed, Apr 13, 2011 at 12:09 AM, Jan Kiszka <jan.kiszka@web.de> wrote: > On 2011-04-12 21:41, Sasha Levin wrote: >> Hello, >> >> I've tried using mmap to map the RAM of a guest instead of >> posix_memalign which is used both in the kvm tool and qemu. >> >> Doing so caused a kernel Oops, which happens every time I run the code >> and was confirmed both on 2.6.38 and the latest git build of 2.6.39. >> > > Can you share the test case that triggers it? That's easier than > guessing what you did precisely. It's the native Linux kvm tool patched to use mmap() instead of posix_memalign(). Sasha, maybe you should post your patch so other people can try to reproduce the problem? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kernel oops in host caused by mmaping RAM 2011-04-13 12:50 ` Pekka Enberg @ 2011-04-13 12:58 ` Sasha Levin 0 siblings, 0 replies; 6+ messages in thread From: Sasha Levin @ 2011-04-13 12:58 UTC (permalink / raw) To: Pekka Enberg; +Cc: Jan Kiszka, kvm On Wed, Apr 13, 2011 at 3:50 PM, Pekka Enberg <penberg@kernel.org> wrote: > On Wed, Apr 13, 2011 at 12:09 AM, Jan Kiszka <jan.kiszka@web.de> wrote: >> On 2011-04-12 21:41, Sasha Levin wrote: >>> Hello, >>> >>> I've tried using mmap to map the RAM of a guest instead of >>> posix_memalign which is used both in the kvm tool and qemu. >>> >>> Doing so caused a kernel Oops, which happens every time I run the code >>> and was confirmed both on 2.6.38 and the latest git build of 2.6.39. >>> >> >> Can you share the test case that triggers it? That's easier than >> guessing what you did precisely. > > It's the native Linux kvm tool patched to use mmap() instead of > posix_memalign(). Sasha, maybe you should post your patch so other > people can try to reproduce the problem? > I provided Jan with a patch to the kvm tool yesterday, Jan has reproduced the oops and sent a patch to kernel-side KVM to fix it. Here's the patch for the Linux kvm tool which triggered the oops. diff --git a/tools/kvm/kvm.c b/tools/kvm/kvm.c index 08ff63c..bac2a5e 100644 --- a/tools/kvm/kvm.c +++ b/tools/kvm/kvm.c @@ -158,7 +158,6 @@ struct kvm *kvm__init(const char *kvm_dev, unsigned long ram_size) struct kvm_userspace_memory_region mem; struct kvm_pit_config pit_config = { .flags = 0, }; struct kvm *self; - long page_size; int ret; if (!kvm__cpu_supports_vm()) @@ -199,8 +198,8 @@ struct kvm *kvm__init(const char *kvm_dev, unsigned long ram_size) self->ram_size = ram_size; - page_size = sysconf(_SC_PAGESIZE); - if (posix_memalign(&self->ram_start, page_size, self->ram_size) != 0) + self->ram_start = mmap(NULL, self->ram_size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS, -1, 0); + if (self == MAP_FAILED) die("out of memory"); mem = (struct kvm_userspace_memory_region) { -- Sasha. ^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH] KVM: VMX: Ensure that vmx_create_vcpu always returns proper error 2011-04-12 19:41 Kernel oops in host caused by mmaping RAM Sasha Levin 2011-04-12 21:09 ` Jan Kiszka @ 2011-04-12 23:27 ` Jan Kiszka 2011-04-16 14:50 ` Marcelo Tosatti 1 sibling, 1 reply; 6+ messages in thread From: Jan Kiszka @ 2011-04-12 23:27 UTC (permalink / raw) To: Sasha Levin; +Cc: kvm, Avi Kivity, Marcelo Tosatti On 2011-04-12 21:41, Sasha Levin wrote: > Hello, > > I've tried using mmap to map the RAM of a guest instead of > posix_memalign which is used both in the kvm tool and qemu. > > Doing so caused a kernel Oops, which happens every time I run the code > and was confirmed both on 2.6.38 and the latest git build of 2.6.39. > > [32109.368018] BUG: unable to handle kernel NULL pointer dereference > at 0000000000000008 > [32109.368018] IP: [<ffffffff810033b0>] kvm_vm_ioctl+0xbc/0x33a > [32109.368018] PGD d7202067 PUD 6a838067 PMD 0 > [32109.368018] Oops: 0002 [#1] PREEMPT SMP > [32109.368018] last sysfs file: > /sys/devices/pci0000:00/0000:00:1f.2/host2/target2:0:0/2:0:0:0/block/sda/uevent > [32109.368018] CPU 0 > [32109.368018] Modules linked in: > [32109.368018] > [32109.368018] Pid: 20829, comm: kvm Not tainted 2.6.38-gentoo-r1 #4 > System manufacturer System Product Name/P5GC-MX/1333 > [32109.368018] RIP: 0010:[<ffffffff810033b0>] [<ffffffff810033b0>] > kvm_vm_ioctl+0xbc/0x33a > [32109.368018] RSP: 0018:ffff880037013e28 EFLAGS: 00010207 > [32109.368018] RAX: 0000000000000000 RBX: ffff880037158000 RCX: 0000000000000000 > [32109.368018] RDX: 0000000000000000 RSI: ffff880037013d78 RDI: 0000000000000206 > [32109.368018] RBP: ffff880037013ea8 R08: ffff880000098e00 R09: 0000000000000004 > [32109.368018] R10: 0000000000000000 R11: ffff880037013ca8 R12: 0000000000000000 > [32109.368018] R13: 000000000000ae41 R14: 0000000000000000 R15: 0000000000000000 > [32109.368018] FS: 00007f83f7cd9700(0000) GS:ffff8800d7c00000(0000) > knlGS:0000000000000000 > [32109.368018] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [32109.368018] CR2: 0000000000000008 CR3: 00000000d062e000 CR4: 00000000000026e0 > [32109.368018] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [32109.368018] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [32109.368018] Process kvm (pid: 20829, threadinfo ffff880037012000, > task ffff88008525d340) > [32109.368018] Stack: > [32109.368018] ffff880037013e48 ffffffff8150d59c ffff88000e9b9308 > ffff88000e9b9308 > [32109.368018] ffff880037013ec8 ffffffff81079e25 ffff8800d7c0e388 > ffff88000e9b9308 > [32109.368018] 0000000000000001 000000000000e380 ffff880037013e98 > ffffffff8105b04e > [32109.368018] Call Trace: > [32109.368018] [<ffffffff8150d59c>] ? _raw_spin_unlock_irqrestore+0x3c/0x49 > [32109.368018] [<ffffffff81079e25>] ? __hrtimer_start_range_ns+0x2b4/0x2c6 > [32109.368018] [<ffffffff8105b04e>] ? get_parent_ip+0x11/0x41 > [32109.368018] [<ffffffff810f1ba9>] do_vfs_ioctl+0x3f1/0x440 > [32109.368018] [<ffffffff8150d59c>] ? _raw_spin_unlock_irqrestore+0x3c/0x49 > [32109.368018] [<ffffffff8107605c>] ? sys_timer_settime+0x254/0x2a4 > [32109.368018] [<ffffffff810f1c49>] sys_ioctl+0x51/0x74 > [32109.368018] [<ffffffff81027a52>] system_call_fastpath+0x16/0x1b > [32109.368018] Code: 40 40 0f 85 70 02 00 00 e9 13 02 00 00 44 89 e6 > 45 89 e6 48 89 df e8 19 6e 00 00 49 89 c4 49 81 fc 00 f0 ff ff 0f 87 > 6f 02 00 00 <49> c7 44 24 08 00 00 00 00 49 c7 44 24 10 00 00 00 00 49 > c7 44 > [32109.368018] RIP [<ffffffff810033b0>] kvm_vm_ioctl+0xbc/0x33a > [32109.368018] RSP <ffff880037013e28> > [32109.368018] CR2: 0000000000000008 > [32109.368018] [drm] force priority to high > [32109.385714] ---[ end trace 0fc207e73803c472 ]--- > Patch below fixes the oops for me. It looks like the problem was that your guest memory setup caused a conflict with the kernel's desire to map the APIC access page. So alloc_apic_access_page failed, but that error was not properly reported back, causing the NULL pointer dereferencing. Thanks for reporting, Jan -----8<------ From: Jan Kiszka <jan.kiszka@siemens.com> In case certain allocations fail, vmx_create_vcpu may return 0 as error instead of a negative value encoded via ERR_PTR. This causes a NULL pointer dereferencing later on in kvm_vm_ioctl_vcpu_create. Reported-by: Sasha Levin <levinsasha928@gmail.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> --- arch/x86/kvm/vmx.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index aabe333..af52069 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -4251,8 +4251,8 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, unsigned int id) goto free_vcpu; vmx->guest_msrs = kmalloc(PAGE_SIZE, GFP_KERNEL); + err = -ENOMEM; if (!vmx->guest_msrs) { - err = -ENOMEM; goto uninit_vcpu; } @@ -4271,7 +4271,8 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, unsigned int id) if (err) goto free_vmcs; if (vm_need_virtualize_apic_accesses(kvm)) - if (alloc_apic_access_page(kvm) != 0) + err = alloc_apic_access_page(kvm); + if (err) goto free_vmcs; if (enable_ept) { -- 1.7.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] KVM: VMX: Ensure that vmx_create_vcpu always returns proper error 2011-04-12 23:27 ` [PATCH] KVM: VMX: Ensure that vmx_create_vcpu always returns proper error Jan Kiszka @ 2011-04-16 14:50 ` Marcelo Tosatti 0 siblings, 0 replies; 6+ messages in thread From: Marcelo Tosatti @ 2011-04-16 14:50 UTC (permalink / raw) To: Jan Kiszka; +Cc: Sasha Levin, kvm, Avi Kivity On Wed, Apr 13, 2011 at 01:27:55AM +0200, Jan Kiszka wrote: > On 2011-04-12 21:41, Sasha Levin wrote: > > Hello, > > > > I've tried using mmap to map the RAM of a guest instead of > > posix_memalign which is used both in the kvm tool and qemu. > > > > Doing so caused a kernel Oops, which happens every time I run the code > > and was confirmed both on 2.6.38 and the latest git build of 2.6.39. > > > > [32109.368018] BUG: unable to handle kernel NULL pointer dereference > > at 0000000000000008 > > [32109.368018] IP: [<ffffffff810033b0>] kvm_vm_ioctl+0xbc/0x33a > > [32109.368018] PGD d7202067 PUD 6a838067 PMD 0 > > [32109.368018] Oops: 0002 [#1] PREEMPT SMP > > [32109.368018] last sysfs file: > > /sys/devices/pci0000:00/0000:00:1f.2/host2/target2:0:0/2:0:0:0/block/sda/uevent > > [32109.368018] CPU 0 > > [32109.368018] Modules linked in: > > [32109.368018] > > [32109.368018] Pid: 20829, comm: kvm Not tainted 2.6.38-gentoo-r1 #4 > > System manufacturer System Product Name/P5GC-MX/1333 > > [32109.368018] RIP: 0010:[<ffffffff810033b0>] [<ffffffff810033b0>] > > kvm_vm_ioctl+0xbc/0x33a > > [32109.368018] RSP: 0018:ffff880037013e28 EFLAGS: 00010207 > > [32109.368018] RAX: 0000000000000000 RBX: ffff880037158000 RCX: 0000000000000000 > > [32109.368018] RDX: 0000000000000000 RSI: ffff880037013d78 RDI: 0000000000000206 > > [32109.368018] RBP: ffff880037013ea8 R08: ffff880000098e00 R09: 0000000000000004 > > [32109.368018] R10: 0000000000000000 R11: ffff880037013ca8 R12: 0000000000000000 > > [32109.368018] R13: 000000000000ae41 R14: 0000000000000000 R15: 0000000000000000 > > [32109.368018] FS: 00007f83f7cd9700(0000) GS:ffff8800d7c00000(0000) > > knlGS:0000000000000000 > > [32109.368018] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [32109.368018] CR2: 0000000000000008 CR3: 00000000d062e000 CR4: 00000000000026e0 > > [32109.368018] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > [32109.368018] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > > [32109.368018] Process kvm (pid: 20829, threadinfo ffff880037012000, > > task ffff88008525d340) > > [32109.368018] Stack: > > [32109.368018] ffff880037013e48 ffffffff8150d59c ffff88000e9b9308 > > ffff88000e9b9308 > > [32109.368018] ffff880037013ec8 ffffffff81079e25 ffff8800d7c0e388 > > ffff88000e9b9308 > > [32109.368018] 0000000000000001 000000000000e380 ffff880037013e98 > > ffffffff8105b04e > > [32109.368018] Call Trace: > > [32109.368018] [<ffffffff8150d59c>] ? _raw_spin_unlock_irqrestore+0x3c/0x49 > > [32109.368018] [<ffffffff81079e25>] ? __hrtimer_start_range_ns+0x2b4/0x2c6 > > [32109.368018] [<ffffffff8105b04e>] ? get_parent_ip+0x11/0x41 > > [32109.368018] [<ffffffff810f1ba9>] do_vfs_ioctl+0x3f1/0x440 > > [32109.368018] [<ffffffff8150d59c>] ? _raw_spin_unlock_irqrestore+0x3c/0x49 > > [32109.368018] [<ffffffff8107605c>] ? sys_timer_settime+0x254/0x2a4 > > [32109.368018] [<ffffffff810f1c49>] sys_ioctl+0x51/0x74 > > [32109.368018] [<ffffffff81027a52>] system_call_fastpath+0x16/0x1b > > [32109.368018] Code: 40 40 0f 85 70 02 00 00 e9 13 02 00 00 44 89 e6 > > 45 89 e6 48 89 df e8 19 6e 00 00 49 89 c4 49 81 fc 00 f0 ff ff 0f 87 > > 6f 02 00 00 <49> c7 44 24 08 00 00 00 00 49 c7 44 24 10 00 00 00 00 49 > > c7 44 > > [32109.368018] RIP [<ffffffff810033b0>] kvm_vm_ioctl+0xbc/0x33a > > [32109.368018] RSP <ffff880037013e28> > > [32109.368018] CR2: 0000000000000008 > > [32109.368018] [drm] force priority to high > > [32109.385714] ---[ end trace 0fc207e73803c472 ]--- > > > > Patch below fixes the oops for me. > > It looks like the problem was that your guest memory setup caused a > conflict with the kernel's desire to map the APIC access page. So > alloc_apic_access_page failed, but that error was not properly reported > back, causing the NULL pointer dereferencing. > > Thanks for reporting, > Jan > > -----8<------ > > From: Jan Kiszka <jan.kiszka@siemens.com> > > In case certain allocations fail, vmx_create_vcpu may return 0 as error > instead of a negative value encoded via ERR_PTR. This causes a NULL > pointer dereferencing later on in kvm_vm_ioctl_vcpu_create. > > Reported-by: Sasha Levin <levinsasha928@gmail.com> > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Applied, thanks. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-04-16 14:56 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-04-12 19:41 Kernel oops in host caused by mmaping RAM Sasha Levin 2011-04-12 21:09 ` Jan Kiszka 2011-04-13 12:50 ` Pekka Enberg 2011-04-13 12:58 ` Sasha Levin 2011-04-12 23:27 ` [PATCH] KVM: VMX: Ensure that vmx_create_vcpu always returns proper error Jan Kiszka 2011-04-16 14:50 ` Marcelo Tosatti
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox