内核函数?

Question

哪位高手能不能给出一些在linux 红帽 as 3.0下编写内核程序的时候可能导致死机的函数？？
自己写的网络监控程序有时候会不定时的死机，后来把所有的局部变量都改为全局变量为了防止栈溢出，还有就是把所有的printk函数都去掉（本来也不是很多，因为有人说这个函数不支持中断）。这样还是会死机，但是明显好了一点。还有个明显的特点是负载有很大关系，如果正常情况下有1400多人在用的话就可能会比较高两天一次。但是现在800多人用的时候可能就是5天死一次。现在是不是应该怀疑有的函数本身可能有问题呢？
还有就是从2.1上挪到3.0上后是不是memset，这样的函数就不好用了，一段ftp程序，感觉能出问题的就这里了，在2.1下能正常运行，但是到了3.0上马上就死机了？
哪位高手给个意见，多谢了先！

Answer 1

多谢楼上的，不是自己写的中断，是网卡自己的中断，我前段时间在网上看到说在printk有可能在这种情况下随即的导致死机。因为主要的处理是网卡上的hook函数，并且我把那个函数去掉后的确也好了点。4楼的说法我试着做一下吧.
其实这个系统是学校用来监控所有的上网记录的，就是所有的同学要上外网的时候都要在这里处理。记录他的信息。现在放假了，只有900多人在用，这此已经运行了7天多了还没有死机。我就在想，有可能是资源竞争的问题。因为从表面上看，的确是负载有一定影响。

Answer 2

中断处理例程中不能休眠，不能执行调度，不能阻塞。有一些函数会导致以上的情况，所以不能在中断处理例程中使用。比如kmalloc()可能会休眠，所以不能用。有点好奇，写网络监控程序为什么自己直接处理中断？用内核提供的api不是更好吗？还有使用全局变量应该注意一下竞态的问题。

Answer 3

我说的信息是在发生kernel panic的时候在控制台输出的信息，它里面包含了panic时的寄存器状态，函数调用关系等，用cat /proc/kmsg可以看到，在死机之前就要用这个命令，而且不要中断他，当死机的时候oops信息就会显示出来了，信息类似于下面的内容：
Unable to handle kernel NULL pointer dereference at virtual address 00000001

NIP: C013A7F0 LR: C013A7F0 SP: C0685E00 REGS: c0905d10 TRAP: 0700
Not tainted
MSR: 00089037 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c0712530[0] 'swapper' Last syscall: 120
GPR00: C013A7C0 C0295E00 C0231530 0000002F 00000001 C0380CB8 C0291B80 C02D0000
GPR08: 000012A0 00000000 00000000 C0292AA0 4020A088 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR24: 00000000 00000005 00000000 00001032 C3F7C000 00000032 FFFFFFFF C3F7C1C0
Call trace:
[c013ab30] tulip_timer+0x128/0x1c4
[c0020744] run_timer_softirq+0x10c/0x164
[c001b864] do_softirq+0x88/0x104
[c0007e80] timer_interrupt+0x284/0x298
[c00033c4] ret_from_except+0x0/0x34
[c0007b84] default_idle+0x20/0x60
[c0007bf8] cpu_idle+0x34/0x38
[c0003ae8] rest_init+0x24/0x34

System.map和vmlinux是在编以内核后生成的。前一个包含的是内核变量/函数和他们地址的映射表，可以通过oops信息找出有问题的函数（在oops信息中有死机时正在运行的函数的地址信息）； 后一个是内核的目标代码，可以将其反汇编，再根据oops信息中的寄存器状态信息，找出具体函数的那一部分代码导致kernel panic。

当然，也并不是所有的死机都会产生oops信息。

Answer 4

多谢楼上的。硬件问题的话可能性应该不是很大，因为都为此换过一台机器。
你说的日志就是/var/log/message里的日志吧，我一直都在看，但是每次死机的时候什么内容都没有。那两个文件我还不懂，不知道有什么具体的用处。
给我的感觉是每次都发生了kernel panic，但是具体原因找不到。总是感觉有些函数用之前可能需要判断，或者说在这种频繁中断的情况下有些函数并不支持，比如printk函数，有一次发生意外的时候，打印了12分钟信息后就kernel panic了。

Answer 5

建议你把死机的时候系统输出的log信息贴出来,因为一般情况下会包含内核的oops信息,同时再附上对应内核的vmlinux和System.map文件,那样就比较容易找出死记的原因了。
死机在一般情况下都是发生了kernel panic，当然也有可能因为硬件的问题导致死机。