[Devel] Kernel panic when vznetdev module not loaded
Dan Bassett
dbassett at oreillyschool.com
Wed Jan 16 08:05:29 PST 2013
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
More information about the Devel
mailing list