[Devel] Kernel panic when vznetdev module not loaded

Dan Bassett dbassett at oreillyschool.com
Wed Jan 16 08:35:20 PST 2013


No joy on 042stab072.9:

[   37.804018] kernel BUG at net/core/dev.c:5503!
[   37.804018] invalid opcode: 0000 [#1] SMP
[   37.804018] last sysfs file: /sys/devices/virtual/net/br0/broadcast
[   37.804018] CPU 0
[   37.804018] Modules linked in: vzethdev pio_nfs pio_direct pfmt_raw 
pfmt_ploop1 ploop simfs vzrst vzcpt nfs lockd fscache nfs_acl 
auth_rpcgss sunrpc vzdquota vzmon vzdev ip6table_mangle xt_length xt_hl 
xt_tcpmss xt_TCPMSS iptable_nat nf_nat iptable_mangle xt_multiport 
xt_limit xt_dscp vzevent bridge stp llc ipt_REJECT nf_conntrack_ipv4 
nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 
nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 
virtio_balloon snd_intel8x0 snd_ac97_codec ac97_bus snd_seq 
snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc virtio_net 
i2c_piix4 i2c_core sg ext4 mbcache jbd2 virtio_blk sr_mod cdrom 
virtio_pci virtio_ring virtio pata_acpi ata_generic ata_piix dm_mirror 
dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
[   37.804018]
[   37.804018] Pid: 1295, comm: vzctl veid: 0 Not tainted 
2.6.32-042stab072.9 #1 042stab072_9 Bochs Bochs
[   37.804018] RIP: 0010:[<ffffffff8143aeaa>]  [<ffffffff8143aeaa>] 
register_netdevice+0x46a/0x4a0
[   37.804018] RSP: 0018:ffff88003ee07cd8  EFLAGS: 00010246
[   37.804018] RAX: 0000000000000000 RBX: ffff88003ecb8020 RCX: 
0000000000000000
[   37.804018] RDX: 0000000000000000 RSI: 0000000000000025 RDI: 
ffff88003ecb8020
[   37.804018] RBP: ffff88003ee07cf8 R08: 0000000000000000 R09: 
0000000000000000
[   37.804018] R10: 0000000000000001 R11: 0000000000000000 R12: 
0000000000000000
[   37.804018] R13: ffff88003ee07dc8 R14: ffff88003ecb8020 R15: 
ffff88003c7fa020
[   37.804018] FS:  00007f05690a8b20(0000) GS:ffff880002600000(0000) 
knlGS:0000000000000000
[   37.804018] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   37.804018] CR2: 00007f05690b1000 CR3: 000000003bccc000 CR4: 
00000000000006f0
[   37.804018] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
0000000000000000
[   37.804018] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
0000000000000400
[   37.804018] Process vzctl (pid: 1295, veid: 0, threadinfo 
ffff88003ee06000, task ffff88003bcc82c0)
[   37.804018] Stack:
[   37.804018]  ffff88003ecb8020 ffff88003ecb8020 ffff88003ee07dc8 
ffff88003ee07dc8
[   37.804018] <d> ffff88003ee07d28 ffffffff8143af1f ffff88003e850858 
ffff88003c7fa020
[   37.804018] <d> ffff88003ee07d28 ffff88003ee07d78 ffff88003ee07d58 
ffffffffa05a151e
[   37.804018] Call Trace:
[   37.804018]  [<ffffffff8143af1f>] register_netdev+0x3f/0x60
[   37.804018]  [<ffffffffa05a151e>] veth_dev_start+0xae/0x160 [vzethdev]
[   37.804018]  [<ffffffffa05a1d4b>] veth_ioctl+0x2db/0x4d0 [vzethdev]
[   37.804018]  [<ffffffffa0393277>] vzctl_ioctl+0x57/0x7c [vzdev]
[   37.804018]  [<ffffffff811ac132>] vfs_ioctl+0x22/0xa0
[   37.804018]  [<ffffffff811ac2d4>] do_vfs_ioctl+0x84/0x580
[   37.804018]  [<ffffffff811ac81f>] sys_ioctl+0x4f/0x80
[   37.804018]  [<ffffffff810e61b5>] ? __audit_syscall_exit+0x265/0x290
[   37.804018]  [<ffffffff8100b102>] system_call_fastpath+0x16/0x1b
[   37.804018] Code: fe ff ff 48 c7 c7 18 3c 80 81 48 89 de 31 c0 e8 70 
4a 0b 00 48 8b bb 80 00 00 00 48 83 e7 ed 48 89 bb 80 00 00 00 e9 81 fe 
ff ff <0f> 0b eb fe 0f 0b eb fe ba 79 15 00 00 48 c7 c6 54 08 80 81 48
[   37.804018] RIP  [<ffffffff8143aeaa>] register_netdevice+0x46a/0x4a0
[   37.804018]  RSP <ffff88003ee07cd8>
[   37.855849] ---[ end trace ecc27ea5daa6eee7 ]---
[   37.856567] Kernel panic - not syncing: Fatal exception
[   37.857386] Pid: 1295, comm: vzctl veid: 0 Tainted: G      D    
---------------    2.6.32-042stab072.9 #1
[   37.858845] Call Trace:
[   37.859254]  [<ffffffff814ef83b>] ? panic+0xa0/0x168
[   37.860042]  [<ffffffff814f3bb4>] ? oops_end+0xe4/0x100
[   37.860834]  [<ffffffff8100f28b>] ? die+0x5b/0x90
[   37.861577]  [<ffffffff814f3454>] ? do_trap+0xc4/0x160
[   37.862368]  [<ffffffff8100ce95>] ? do_invalid_op+0x95/0xb0
[   37.863246]  [<ffffffff8143aeaa>] ? register_netdevice+0x46a/0x4a0
[   37.864216]  [<ffffffff811834e0>] ? cache_alloc_refill+0x1b0/0x230
[   37.865194]  [<ffffffff81182140>] ? ub_slab_ptr+0x20/0x90
[   37.866036]  [<ffffffff810aa45c>] ? ub_slab_charge+0xac/0x100
[   37.866911]  [<ffffffff8100bf3b>] ? invalid_op+0x1b/0x20
[   37.867749]  [<ffffffff8143aeaa>] ? register_netdevice+0x46a/0x4a0
[   37.868701]  [<ffffffff8143aa7e>] ? register_netdevice+0x3e/0x4a0
[   37.869636]  [<ffffffff8143af1f>] ? register_netdev+0x3f/0x60
[   37.870514]  [<ffffffffa05a151e>] ? veth_dev_start+0xae/0x160 [vzethdev]
[   37.871571]  [<ffffffffa05a1d4b>] ? veth_ioctl+0x2db/0x4d0 [vzethdev]
[   37.872567]  [<ffffffffa0393277>] ? vzctl_ioctl+0x57/0x7c [vzdev]
[   37.873525]  [<ffffffff811ac132>] ? vfs_ioctl+0x22/0xa0
[   37.874336]  [<ffffffff811ac2d4>] ? do_vfs_ioctl+0x84/0x580
[   37.875217]  [<ffffffff811ac81f>] ? sys_ioctl+0x4f/0x80
[   37.876020]  [<ffffffff810e61b5>] ? __audit_syscall_exit+0x265/0x290
[   37.876982]  [<ffffffff8100b102>] ? system_call_fastpath+0x16/0x1b

Would you like me to file a formal bug report in the Bugzilla?

Dan

On 01/16/2013 10:13 AM, Kirill Kolyshkin wrote:
> Dan,
>
> Thanks for the bugreport, we will look into it. I suggest you to try 042stab072.9 kernel.
> --
> sent from android
>
> Dan Bassett<dbassett at oreillyschool.com>  wrote:
>
>
> I have been investigating using OpenVZ as a tool for providing our
> students with VMs to learn systems administration on.  Currently we use
> UML, but we've found the resource usage to be much too high for our
> liking :-)  Anyway, my goal is to provide a VM that appears to be as
> close to a physical machine as possible, and to that end, I would like
> to remove the venet interface from the CTs and only use veths.  I've
> read all the docs on the OpenVZ wiki and I understand how this is a
> possible security issue, but since this will be a learning sandbox and
> not a production environment, we are comfortable with the risks.
>
> Following the documentation on the OpenVZ wiki
> (http://wiki.openvz.org/Disable_venet_interface) results in a HN that
> does not load the vznetdev kernel driver.  This seems to make sense, and
> the venet interface is not created on the HN.  However, starting a CT
> generated with a CentOS6 template obtained from the OpenVZ project
> results in the following kernel panic on the HN:
>
> [   78.108015] kernel BUG at net/core/dev.c:5503!
> [   78.108015] invalid opcode: 0000 [#1] SMP
> [   78.108015] last sysfs file: /sys/module/vzdev/refcnt
> [   78.108015] CPU 0
> [   78.108015] Modules linked in: vzethdev pio_nfs pio_direct pfmt_raw
> pfmt_ploop1 ploop simfs vzrst vzcpt nfs lockd fscache nfs_acl
> auth_rpcgss sunrpc vzdquota vzmon vzdev ip6table_mangle xt_length xt_hl
> xt_tcpmss xt_TCPMSS iptable_nat nf_nat iptable_mangle xt_multiport
> xt_limit xt_dscp vzevent bridge stp llc ipt_REJECT nf_conntrack_ipv4
> nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6
> nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6
> virtio_balloon snd_intel8x0 snd_ac97_codec ac97_bus snd_seq
> snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc virtio_net
> i2c_piix4 i2c_core sg ext4 mbcache jbd2 virtio_blk sr_mod cdrom
> virtio_pci virtio_ring virtio pata_acpi ata_generic ata_piix dm_mirror
> dm_region_hash dm_log dm_mod [last unloaded: vznetdev]
> [   78.108015]
> [   78.108015] Pid: 1329, comm: vzctl veid: 0 Not tainted
> 2.6.32-042stab068.8 #1 042stab068_8 Bochs Bochs
> [   78.108015] RIP: 0010:[<ffffffff81449ada>]  [<ffffffff81449ada>]
> register_netdevice+0x46a/0x4a0
> [   78.108015] RSP: 0018:ffff88003e83dcd8  EFLAGS: 00010246
> [   78.108015] RAX: 0000000000000000 RBX: ffff88003ef53020 RCX:
> 0000000000000000
> [   78.108015] RDX: 0000000000000000 RSI: 0000000000000025 RDI:
> ffff88003ef53020
> [   78.108015] RBP: ffff88003e83dcf8 R08: 0000000000000000 R09:
> ffff88003ec66540
> [   78.108015] R10: 0000000000000001 R11: 0000000000000000 R12:
> 0000000000000000
> [   78.108015] R13: ffff88003e83ddc8 R14: ffff88003ef53020 R15:
> ffff88003eefe020
> [   78.108015] FS:  00007f39e14f5b20(0000) GS:ffff880002600000(0000)
> knlGS:0000000000000000
> [   78.108015] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   78.108015] CR2: 00007f39e14fe000 CR3: 000000003eec8000 CR4:
> 00000000000006f0
> [   78.108015] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [   78.108015] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [   78.108015] Process vzctl (pid: 1329, veid: 0, threadinfo
> ffff88003e83c000, task ffff88003c1ce240)
> [   78.108015] Stack:
> [   78.108015]  ffff88003ef53020 ffff88003ef53020 ffff88003e83ddc8
> ffff88003e83ddc8
> [   78.108015]<d>  ffff88003e83dd28 ffffffff81449b4f ffff88003ee26858
> ffff88003eefe020
> [   78.108015]<d>  ffff88003e83dd28 ffff88003e83dd78 ffff88003e83dd58
> ffffffffa05b651e
> [   78.108015] Call Trace:
> [   78.108015]  [<ffffffff81449b4f>] register_netdev+0x3f/0x60
> [   78.108015]  [<ffffffffa05b651e>] veth_dev_start+0xae/0x160 [vzethdev]
> [   78.108015]  [<ffffffffa05b6d4b>] veth_ioctl+0x2db/0x4d0 [vzethdev]
> [   78.108015]  [<ffffffffa0397277>] vzctl_ioctl+0x57/0x7c [vzdev]
> [   78.108015]  [<ffffffff811afe72>] vfs_ioctl+0x22/0xa0
> [   78.108015]  [<ffffffff811b0014>] do_vfs_ioctl+0x84/0x5b0
> [   78.108015]  [<ffffffff811b058f>] sys_ioctl+0x4f/0x80
> [   78.108015]  [<ffffffff8100b182>] system_call_fastpath+0x16/0x1b
> [   78.108015] Code: fe ff ff 48 c7 c7 90 37 80 81 48 89 de 31 c0 e8 d1
> 66 0b 00 48 8b bb 80 00 00 00 48 83 e7 ed 48 89 bb 80 00 00 00 e9 81 fe
> ff ff<0f>  0b eb fe 0f 0b eb fe ba 79 15 00 00 48 c7 c6 e4 03 80 81 48
> [   78.108015] RIP  [<ffffffff81449ada>] register_netdevice+0x46a/0x4a0
> [   78.108015]  RSP<ffff88003e83dcd8>
> [   78.163553] ---[ end trace 435a938e5849ed59 ]---
> [   78.164265] Kernel panic - not syncing: Fatal exception
> [   78.165058] Pid: 1329, comm: vzctl veid: 0 Tainted: G      D
> ---------------    2.6.32-042stab068.8 #1
> [   78.166607] Call Trace:
> [   78.166986]  [<ffffffff815000cc>] ? panic+0xa0/0x168
> [   78.167785]  [<ffffffff815043a4>] ? oops_end+0xe4/0x100
> [   78.168620]  [<ffffffff8100f31b>] ? die+0x5b/0x90
> [   78.169463]  [<ffffffff81503c44>] ? do_trap+0xc4/0x160
> [   78.170289]  [<ffffffff8100cef5>] ? do_invalid_op+0x95/0xb0
> [   78.171172]  [<ffffffff81449ada>] ? register_netdevice+0x46a/0x4a0
> [   78.172142]  [<ffffffff81185fb0>] ? cache_alloc_refill+0x1b0/0x230
> [   78.173097]  [<ffffffff811854e0>] ? ub_slab_ptr+0x20/0x90
> [   78.173961]  [<ffffffff8100bf9b>] ? invalid_op+0x1b/0x20
> [   78.174833]  [<ffffffff81449ada>] ? register_netdevice+0x46a/0x4a0
> [   78.175801]  [<ffffffff814496ac>] ? register_netdevice+0x3c/0x4a0
> [   78.176735]  [<ffffffff81449b4f>] ? register_netdev+0x3f/0x60
> [   78.177764]  [<ffffffffa05b651e>] ? veth_dev_start+0xae/0x160 [vzethdev]
> [   78.178840]  [<ffffffffa05b6d4b>] ? veth_ioctl+0x2db/0x4d0 [vzethdev]
> [   78.179848]  [<ffffffffa0397277>] ? vzctl_ioctl+0x57/0x7c [vzdev]
> [   78.180796]  [<ffffffff811afe72>] ? vfs_ioctl+0x22/0xa0
> [   78.181618]  [<ffffffff811b0014>] ? do_vfs_ioctl+0x84/0x5b0
> [   78.182539]  [<ffffffff811b058f>] ? sys_ioctl+0x4f/0x80
> [   78.183352]  [<ffffffff8100b182>] ? system_call_fastpath+0x16/0x1b
>
> The HN is running a stock CentOS6 install, with the OpenVZ kernel
> installed directly from OpenVZ's yum repo (Linux
> centos6.office.useractive.com 2.6.32-042stab068.8 #1 SMP Fri Dec 7
> 17:06:14 MSK 2012 x86_64 x86_64 x86_64 GNU/Linux).  So before I went off
> and filed a bug in the OpenVZ Bugzilla, I wanted to ask if running
> without the venet interface by not loading the vznetdev module is a
> supported config, or if it is no longer (or was never) supported.  Thanks!
>
> Dan
>
> _______________________________________________
> Devel mailing list
> Devel at openvz.org
> http://lists.openvz.org/mailman/listinfo/devel
>    



More information about the Devel mailing list