mmu.c:307 BUG with kvm-48

FYI,

I got this BUG while playing around with some guests with kvm-48 on a Core2 system. Base kernel was 2.6.23+ff patches (that is why you see the LBR output; BTW that makes KVM complain too when it happens in a guest) . Haven't looked at it closely.

-Andi

------------[ cut here ]------------
kernel BUG at /home/src2/kvm-48/kernel/mmu.c:307!
invalid opcode: 0000 [1] SMP 
CPU 1 
Modules linked in: kvm_intel kvm xfrm_user xfrm4_tunnel af_key usblp cifs deflate zlib_deflate zlib_inflate twofish_x86_64 twofish_common serpent des md5 sha1 tunnel4 ipcomp esp4 ah4 sha256 pppoe pppox autofs4 ppp_generic snd_pcm_oss slhc snd_mixer_oss snd_seq ipt_MASQUERADE iptable_nat nf_nat_sip nf_conntrack_sip nf_nat_ftp nf_nat_irc nf_nat ip6t_LOG ip6t_REJECT ip6table_filter ip6_tables nf_conntrack_ipv4 xt_state cbc blkcipher nf_conntrack_ftp nf_conntrack_irc cpufreq_conservative nf_conntrack xt_tcpudp ipt_LOG ipt_REJECT iptable_filter ip_tables dm_crypt x_tables aes_x86_64 binfmt_misc eeprom lm85 hwmon_vid snd_usb_audio snd_usb_lib snd_hda_intel snd_rawmidi snd_pcm snd_seq_device snd_timer snd_hwdep pl2303 snd usbserial appledisplay i2c_i801 snd_page_alloc i2c_core
Pid: 9021, comm: qemu-system-x86 Not tainted 2.6.23-BASIL #146
RIP: 0010:[<ffffffff881aa41f>]  [<ffffffff881aa41f>] :kvm:mmu_memory_cache_alloc+0xd/0x29
RSP: 0018:ffff810109bd19d8  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff810060990780 RCX: 0000000000000028
RDX: ffff810060990780 RSI: 0000000000000028 RDI: ffff810103ddc318
RBP: ffff810103ddc000 R08: 0000000000000000 R09: 0000000000000004
R10: 8000000016c6b027 R11: 0000000103ddc000 R12: ffff81004da46230
R13: 0000000000000004 R14: ffff810103ddc000 R15: ffff81004da46230
FS:  00002b89e3fb76e0(0000) GS:ffff81011fc10100(0000) knlGS:0000000000000000
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000080464fc CR3: 0000000115022000 CR4: 00000000000026e0
DR0: ffffffff804df6a0 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff4ff1 DR7: 0000000000000702

Process qemu-system-x86 (pid: 9021, threadinfo ffff810109bd0000, task ffff810070005530) last branch before last exception/interrupt
from [<ffffffff881a7752>] :kvm:kvm_vcpu_ioctl+0x579/0xf57
to [<ffffffff881a5078>] :kvm:kvm_load_guest_fpu+0x0/0x31

Stack:  0000000000016c6b ffffffff881aa50c 80000000854c7045 00000000854c7000
 8000000000000045 ffffffff881aaef3 0000000000000001 0000000000016c6b
 0000000000000000 0000000000000000 0000000016c6b000 0000000016c6b000
Call Trace:
 [<ffffffff881aa50c>] :kvm:rmap_add+0xc3/0xeb
 [<ffffffff881aaef3>] :kvm:paging64_set_pte_common+0x1c5/0x22e
 [<ffffffff881aafa6>] :kvm:paging64_set_pte+0x4a/0x4f
 [<ffffffff881ab264>] :kvm:kvm_mmu_pte_write+0x2b9/0x329
 [<ffffffff881a6616>] :kvm:emulator_write_emulated_onepage+0x6e/0xce
 [<ffffffff881b0cec>] :kvm:x86_emulate_insn+0x410a/0x4152
 [<ffffffff881ac438>] :kvm:x86_decode_insn+0x27b/0xa25
 [<ffffffff881a6af5>] :kvm:emulate_instruction+0x152/0x290
 [<ffffffff88249a55>] :kvm_intel:handle_exception+0x170/0x24a
 [<ffffffff881a7530>] :kvm:kvm_vcpu_ioctl+0x357/0xf57
 [<ffffffff8025bf27>] file_read_actor+0xa0/0x11d
 [<ffffffff8022b79d>] enqueue_entity+0x17c/0x1a3
 [<ffffffff8022ab03>] enqueue_task+0x13/0x21
 [<ffffffff8022b4d5>] inc_nr_running+0x19/0x32
 [<ffffffff8022dd6d>] try_to_wake_up+0x330/0x342
 [<ffffffff80288c77>] core_sys_select+0x234/0x265
 [<ffffffff8022c866>] __wake_up+0x38/0x4e
 [<ffffffff8023cbe8>] __dequeue_signal+0x19/0x15a
 [<ffffffff8023c4e7>] recalc_sigpending+0xe/0x25
 [<ffffffff8023e002>] dequeue_signal+0x8d/0x115
 [<ffffffff80248d64>] getnstimeofday+0x32/0x8a
 [<ffffffff80287a5d>] do_ioctl+0x21/0x6b
 [<ffffffff80287cea>] vfs_ioctl+0x243/0x25c
 [<ffffffff80287d3f>] sys_ioctl+0x3c/0x5d
 [<ffffffff8020bb6e>] system_call+0x7e/0x83


Code: 0f 0b eb fe ff c8 89 07 48 98 48 8b 54 c7 08 31 c0 fc 48 89 
RIP  [<ffffffff881aa41f>] :kvm:mmu_memory_cache_alloc+0xd/0x29
 RSP <ffff810109bd19d8>

ISO 9660 Extensions: RRIP_1991A

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

it look like the slab cache is not initlized for some reason, there was fix in kvm-49 that initied the slab cache in another place. (check out commits arround b95061aec006bc4c44e4b244e4ec15c009ab880a)

can you please check if it happen in kvm-49 as well?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

I can try it next time and see if it happens again. It is not easily reproducible (that would fit the uninitialized memory theory)

-Andi

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

kvm-49 indeed has the fix "uninitialized memory" is perhaps not the most accurate description. Rather, the slab preallocation cache (which kvm uses to ensure allocations don't fail) underflowed due to changes in how kvm consumes rmap entries; we now refill it at the correct place.

Any sufficiently difficult bug is indistinguishable from a feature.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/