为什么rmmod ip_vs导致机器崩溃?

时间:2018-10-19 04:14:30

标签: kernel

一个内核ip_vs oops问题,任何建议都将不胜感激。

我从suse11 sp3的源代码编译了ip_vs.ko(用于lvs的内核模块),并在完全相同的verion机器上使用了此ko。这是版本信息:

SZX1000476745:~ # uname -a
Linux SZX1000476745 3.0.76-0.11-default #1 SMP Fri Jun 14 08:21:43 UTC 2013 (ccab990) x86_64 x86_64 x86_64 GNU/Linux
SZX1000476745:~ # cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3

在使用insmod加载ip_vs.ko之后,当我使用rmmod卸载ip_vs时,有时会引起哎呀。(概率很小) 我在代码中添加了一些日志:

net / netfilter / ipvs / ip_vs_ctl.c

static int ip_vs_dst_event(struct notifier_block *this, unsigned long event, void *ptr)

    printk(KERN_INFO "dddddddd^_^");
    j=0;
    list_for_each_entry(dest, &ipvs->dest_trash, n_list) {
        j++;
        printk(KERN_INFO "eeeeee^_^ j:%d", j);
        printk(KERN_INFO "eeeeee^_^ ipvs:%p", ipvs);
        printk(KERN_INFO "eeeeee^_^ dest:%p", dest);
        printk(KERN_INFO "eeeeee^_^ dest->dst_lock:%p", &dest->dst_lock);
        __ip_vs_dev_reset(dest, dev);
    }

在内核崩溃之后,我在

中获得了这些信息。

/var/crash/xxxx/dmesg.txt

<6>[ 4043.888540] dddddddd^_^
    <6>[ 4043.888542] eeeeee^_^ j:1
    <6>[ 4043.888543] eeeeee^_^ ipvs:ffff8803b202e000
    <6>[ 4043.888545] eeeeee^_^ dest:0000000000000001
    <6>[ 4043.888547] eeeeee^_^ dest->dst_lock:000000000000011d
    <1>[ 4043.888572] BUG: unable to handle kernel NULL pointer dereference at 000000000000011d
    <1>[ 4043.888580] IP: [<ffffffff8145c9de>] _raw_spin_lock_bh+0xe/0x30
    <4>[ 4043.888592] PGD 3ffd1a067 PUD 402619067 PMD 0
    <0>[ 4043.888598] Oops: 0002 [#1] SMP
    <4>[ 4043.888603] CPU 5
    <4>[ 4043.888605] Modules linked in: ip_vs(FN-) lvsCoreDumpTest(FN) ip6_tables(FN) acpiphp pci_hotplug edd bluetooth rfkill crc16 mperf af_packet xt_tcpudp iptable_filter ip_tables x_tables crc32c libcrc32c(FN) nf_conntrack(FN) fuse loop dm_mod joydev usbhid hid ipv6 ipv6_lib i2c_piix4 i2c_core intel_agp pcspkr intel_gtt floppy rtc_cmos sg sr_mod button ext3 jbd mbcache uhci_hcd ehci_hcd processor thermal_sys hwmon usbcore usb_common scsi_dh_hp_sw scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh ata_generic ata_piix libata xen_hcall(FN) virtio_pci(F) virtio_net(F) virtio(F) virtio_ring(F) xen_vmdq(FN) xen_scsi(FN) scsi_mod xen_vbd(FN) cdrom xen_vnif(FN) xen_balloon(FN) xen_platform_pci(FN) [last unloaded: ip_vs]
    <4>[ 4043.888672] Supported: No, Unsupported modules are loaded
    <4>[ 4043.888675]
    <4>[ 4043.888679] Pid: 16334, comm: rmmod Tainted: GF          N  3.0.76-0.11-default #1 Xen HVM domU
    <4>[ 4043.888684] RIP: 0010:[<ffffffff8145c9de>]  [<ffffffff8145c9de>] _raw_spin_lock_bh+0xe/0x30
    <4>[ 4043.888692] RSP: 0018:ffff8803b6b5de08  EFLAGS: 00010206
    <4>[ 4043.888695] RAX: 0000000000010000 RBX: 000000000000011d RCX: 000000000000ee7c
    <4>[ 4043.888699] RDX: 000000000000ee7c RSI: ffff880405208000 RDI: 000000000000011d
    <4>[ 4043.888703] RBP: 000000000000011d R08: ffffffff81d9cfc0 R09: 0000000000000000
    <4>[ 4043.888706] R10: 0000000000000006 R11: 00000000ffffffff R12: ffff880405208000
    <4>[ 4043.888710] R13: ffffffffa03e1690 R14: ffff8803b202e000 R15: ffffffff81a72280
    <4>[ 4043.888715] FS:  00007fea7eb9c700(0000) GS:ffff88041dea0000(0000) knlGS:0000000000000000
    <4>[ 4043.888719] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    <4>[ 4043.888722] CR2: 000000000000011d CR3: 000000040301f000 CR4: 00000000001406e0
    <4>[ 4043.888732] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    <4>[ 4043.888736] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    <4>[ 4043.888742] Process rmmod (pid: 16334, threadinfo ffff8803b6b5c000, task ffff8803ffcb81c0)
    <0>[ 4043.888745] Stack:
    <4>[ 4043.888747]  0000000000000001 ffffffffa03c6bd7 0000000000000001 ffff8803b202e600
    <4>[ 4043.888754]  0000000000000001 ffffffffa03c7959 ffffc90002644fff ffff880405208000
    <4>[ 4043.888759]  0000008000000000 ffff8803dbdc4980 ffff8803b2284a00 0020000000000000
    <0>[ 4043.888765] Call Trace:
    <4>[ 4043.888783]  [<ffffffffa03c6bd7>] __ip_vs_dev_reset+0x27/0x70 [ip_vs]
    <4>[ 4043.888810]  [<ffffffffa03c7959>] ip_vs_dst_event+0x269/0x370 [ip_vs]
    <4>[ 4043.888824]  [<ffffffff8139e506>] unregister_netdevice_notifier+0x76/0xf0
    <4>[ 4043.888833]  [<ffffffffa03c7aa0>] ip_vs_control_cleanup+0x10/0x30 [ip_vs]
    <4>[ 4043.888846]  [<ffffffffa03d604a>] ip_vs_cleanup+0x4a/0x1000 [ip_vs]
    <4>[ 4043.888856]  [<ffffffff8109e640>] sys_delete_module+0x180/0x280
    <4>[ 4043.888866]  [<ffffffff81464592>] system_call_fastpath+0x16/0x1b
    <4>[ 4043.888877]  [<00007fea7e511307>] 0x7fea7e511306
    <0>[ 4043.888879] Code: fb e8 57 9d c0 ff 48 89 df f0 83 2f 01 79 05 e8 f9 0c e0 ff 5b c3 0f 1f 80 00 00 00 00 53 48 89 fb e8 37 9d c0 ff b8 00 00 01 00 <f0> 0f c1 03 0f b7 d0 c1 e8 10 39 c2 74 07 f3 90 0f b7 13 eb f5
    <1>[ 4043.888915] RIP  [<ffffffff8145c9de>] _raw_spin_lock_bh+0xe/0x30
    <4>[ 4043.888921]  RSP <ffff8803b6b5de08>
    <0>[ 4043.888924] CR2: 000000000000011d

这让我很困惑,在 net / netfilter / ipvs / ip_vs_core.c 中,似乎ip_vs_control_cleanup()在{{之后使用了一个内存块(ip_vs结构) 1}}释放了它。

net / netfilter / ipvs / ip_vs_core.c

unregister_pernet_subsys(&ipvs_core_ops)

这是我发现与该错误类似的错误: https://www.systutorials.com/linux-kernels/22324/ipvs-fix-oops-in-ip_vs_dst_event-on-rmmod-linux-3-0-47/

  1. 这是一个内核错误吗?如果是,那么如何存在这样一个简单的错误(释放后仍使用内存块)?
  2. 我该如何解决?

0 个答案:

没有答案