KVM & Qemu crashed with infinite recursive kernel loop in the guest

[Zdenek Kabelac]

Hi

While testing something inside the Qemu I've accidentally created
infinite fast recursive loop with locked IRQ that instead of
deadlocking guest kernel inside Qemu actually caused some troubles to
the hosting system. (but the system survived)

Using 64bit kernels and git 2.6.25-rc3

 ------------[ cut here ]------------
 WARNING: at arch/x86/kvm/x86.c:158 kvm_queue_exception_e+0x61/0x70 [kvm]()
 Modules linked in: loop tun i915 drm ipt_MASQUERADE iptable_nat
nf_nat nf_conntrack_ipv4 xt_s
tate nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables
x_tables bridge llc nfsd lockd nfs_acl auth_rpcgss exportfs autofs4
sunrpc bin
fmt_misc dm_mirror dm_multipath dm_mod uinput kvm_intel kvm
snd_hda_intel snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device
snd_pcm_oss sn
d_mixer_oss snd_pcm mmc_block arc4 ecb crypto_blkcipher cryptomgr
sr_mod snd_timer crypto_algapi sdhci i2c_i801 cdrom snd psmouse
rtc_cmos rtc
_core serio_raw iwl3945 mac80211 cfg80211 soundcore iTCO_wdt
iTCO_vendor_support e1000e snd_page_alloc ac intel_agp thinkpad_acpi
hwmon backli
ght rtc_lib i2c_core mmc_core evdev nvram button uhci_hcd ohci_hcd
ehci_hcd usbcore [last unloaded: battery]
Pid: 1856, comm: qemu-kvm Not tainted 2.6.25-rc3 #85

Call Trace:
 [<ffffffff8103e54f>] warn_on_slowpath+0x5f/0x90
 [<ffffffff8824a011>] ? :kvm:gfn_to_hva+0x11/0x90
 [<ffffffff8824a2b2>] ? :kvm:kvm_read_guest_page+0x62/0x70
 [<ffffffff81179160>] ? __down_read_trylock+0x20/0x60
 [<ffffffff8824a308>] ? :kvm:kvm_read_guest+0x48/0x90
 [<ffffffff81179160>] ? __down_read_trylock+0x20/0x60
 [<ffffffff88253580>] ? :kvm:paging64_walk_addr+0x180/0x320
 [<ffffffff8824efd1>] :kvm:kvm_queue_exception_e+0x61/0x70
 [<ffffffff88250118>] :kvm:kvm_inject_page_fault+0x38/0x60
 [<ffffffff882539fe>] :kvm:paging64_page_fault+0x27e/0x4d0
 [<ffffffff88250370>] ? :kvm:emulator_write_emulated+0x70/0x90
 [<ffffffff88254b22>] ? :kvm:x86_emulate_insn+0x3e2/0x4dd0
 [<ffffffff8826aede>] ? :kvm_intel:vcpu_put_rsp_rip+0x2e/0x40
 [<ffffffff8826aea5>] ? :kvm_intel:vmx_set_rflags+0x25/0x30
 [<ffffffff88252cba>] :kvm:kvm_mmu_page_fault+0x1a/0xb0
 [<ffffffff8826bfd5>] :kvm_intel:handle_exception+0x1e5/0x280
 [<ffffffff8826a705>] :kvm_intel:kvm_handle_exit+0x75/0xc0
 [<ffffffff8824f666>] :kvm:kvm_arch_vcpu_ioctl_run+0x286/0x760
 [<ffffffff8824966e>] :kvm:kvm_vcpu_ioctl+0x38e/0x3a0
 [<ffffffff812efe49>] ? mutex_unlock+0x9/0x10
 [<ffffffff8108fcd4>] ? generic_file_aio_write+0x74/0xd0
 [<ffffffff811161f6>] ? ext3_file_write+0x26/0xc0
 [<ffffffff810bae01>] ? do_sync_write+0xf1/0x140
 [<ffffffff8824aba5>] ? :kvm:kvm_vm_ioctl+0x85/0x220
 [<ffffffff8110057c>] ? dnotify_parent+0x3c/0xa0
 [<ffffffff810c95b1>] vfs_ioctl+0x31/0xa0
 [<ffffffff810c98a3>] do_vfs_ioctl+0x283/0x2f0
 [<ffffffff810c99a9>] sys_ioctl+0x99/0xa0
 [<ffffffff8100c70a>] system_call_after_swapgs+0x8a/0x8f

And these were  repeated in the log many many time possible even mixed
with some different back traces - but this should be the primary
reason.

Zdenek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/