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
On 02/28/2008 05:25 AM, Zdenek Kabelac wrote:
[cc: Avi]
>
> 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.
>