请教mem_cache_alloc引起的oops-熟悉内存管理的同学指点一下

独孤九贱

在我的系统(linux 32bit 2.6.38.8 + e1000e 82574L)上，出现好几次oops，看起来，都是驱动申请分配skb引起的。怀疑是驱动bug,换了几个版本的e1000e驱动，故障依旧。今天试了一下另外一个系统liniux 64bit 3.2.28 + e1000e 82574L，不同的机器，不同的环境，又出现类似的错误。这两个系统相同之处在于基本相同的内核配置和其它一些我自己写的程序。所以我估计问题应该不是出在驱动在，而多半出在我自己身上，但是是有哪些情况会导致类似这样的slub分配出错呢？？请各位指点一二。

附oops信息：

1. # [ 6400.452544] general protection fault: 0000 [#1] SMP
   
2. [ 6400.456241] CPU 2
   
3. [ 6400.456241] Modules linked in:  ixgbe(O) igb(O) e1000e(O) r8168(O)
   
4. [ 6400.456241]
   
5. [ 6400.456241] Pid: 0, comm: swapper/2 Tainted: G           O 3.2.28 #74 To Be F
   
6. illed By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M.
   
7. [ 6400.456241] RIP: 0010:[<ffffffff810fce90>]  [<ffffffff810fce90>] kmem_cache_a
   
8. lloc+0x40/0x110
   
9. [ 6400.456241] RSP: 0018:ffff88007f303c20  EFLAGS: 00010286
   
10. [ 6400.456241] RAX: 0000000000000000 RBX: ffff880002c58000 RCX: 4be350e100000000
    
11. 
    
12. [ 6400.456241] RDX: 4be350e0ffffffff RSI: 0000000000014a40 RDI: ffffffff815f9a31
    
13. 
    
14. [ 6400.456241] RBP: ffff88007f303c70 R08: ffffffffffffffff R09: 0000000000000000
    
15. 
    
16. [ 6400.456241] R10: ffff880002cb0600 R11: 0000000000000000 R12: 8354c740ffff8800
    
17. 
    
18. [ 6400.456241] R13: ffff88007c8026c0 R14: ffff88007c8026c0 R15: 0000000000000632
    
19. 
    
20. [ 6400.456241] FS:  0000000000000000(0000) GS:ffff88007f300000(0000) knlGS:00000
    
21. 00000000000
    
22. [ 6400.456241] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    
23. [ 6400.456241] CR2: 00007f26c3171f16 CR3: 0000000002efc000 CR4: 00000000000006e0
    
24. 
    
25. [ 6400.456241] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    
26. 
    
27. [ 6400.456241] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    
28. 
    
29. [ 6400.456241] Process swapper/2 (pid: 0, threadinfo ffff88007c8cc000, task ffff
    
30. 88007c8bda40)
    
31. [ 6400.456241] Stack:
    
32. [ 6400.456241]  0000000000000000 ffffffff81ca8680 ffff880002c58000 0000002081ca8
    
33. 6c0
    
34. [ 6400.456241]  ffff88007f303ca0 ffff880002c58000 0000000000000000 0000000000000
    
35. 020
    
36. [ 6400.456241]  ffff88007c8026c0 0000000000000632 ffff88007f303cb0 ffffffff815f9
    
37. a31
    
38. [ 6400.456241] Call Trace:
    
39. [ 6400.456241]  <IRQ>
    
40. [ 6400.456241]  [<ffffffff815f9a31>] __alloc_skb+0x41/0x230
    
41. [ 6400.456241]  [<ffffffff815fa08f>] __netdev_alloc_skb+0x1f/0x40
    
42. [ 6400.456241]  [<ffffffffa0041b0f>] e1000_alloc_rx_buffers+0x1cf/0x2d0 [e1000e]
    
43. 
    
44. [ 6400.456241]  [<ffffffff81009270>] ? nommu_map_sg+0xe0/0xe0
    
45. [ 6400.456241]  [<ffffffffa0040b67>] e1000_clean_rx_irq+0x2c7/0x3b0 [e1000e]
    
46. [ 6400.456241]  [<ffffffffa0044af7>] e1000e_poll+0x77/0x400 [e1000e]
    
47. [ 6400.456241]  [<ffffffff81606822>] net_rx_action+0x92/0x1e0
    
48. [ 6400.456241]  [<ffffffff81049ff9>] __do_softirq+0x99/0x210
    
49. [ 6400.456241]  [<ffffffff817855ec>] call_softirq+0x1c/0x26
    
50. [ 6400.456241]  [<ffffffff8100453d>] do_softirq+0x4d/0x80
    
51. [ 6400.456241]  [<ffffffff8104a3ce>] irq_exit+0x8e/0xb0
    
52. [ 6400.456241]  [<ffffffff8100411e>] do_IRQ+0x5e/0xd0
    
53. [ 6400.456241]  [<ffffffff8178306b>] common_interrupt+0x6b/0x6b
    
54. [ 6400.456241]  <EOI>
    
55. [ 6400.456241]  [<ffffffff8100ae92>] ? mwait_idle+0xa2/0x200
    
56. [ 6400.456241]  [<ffffffff81001186>] cpu_idle+0xc6/0x110
    
57. [ 6400.456241]  [<ffffffff81770aa4>] start_secondary+0x1e7/0x1ee
    
58. [ 6400.456241] Code: 8b 7d 08 89 75 cc 49 8b 4d 00 65 48 03 0c 25 68 cb 00 00 48
    
59. 8b 51 08 4c 8b 21 4d 85 e4 74 6d 49 63 45 20 49 8b 75 00 48 8d 4a 01 <49> 8b 1c
    
60. 04 4c 89 e0 65 48 0f c7 0e 0f 94 c0 84 c0 74 c8 4d 85

复制代码

hmsghnh

这个问题一看上去就很难搞啊。
会不会是内存访问越界了，破坏了 slab的信息。
不知道把崩溃时的内存dump下来，检查一下slab的各个结构的内容有没有帮助。
以前碰到过 crash工具读不出dump文件的slab信息的情况，有高人说可能slab被破坏了。
不知道什么情况比较容易导致这些内存污染的情况

embeddedlwp

楼主上次那个《请教系统内存泄露》帖子，怎么处理的没有分享出来啊。以后时间长了，就没人帮你分析问题啦。

eexplorer

对slub不太熟，但是这种general protection fault一般都是你的code 内存访问越界，破坏了slub数据结构，导致它访问了一些illegal的memory area，比如去写page 0...

可以加slub_debug加到kernel command line，这样就会打开slub debug option, slub会帮你检查有没有memory越界。

独孤九贱

embeddedlwp 发表于 2012-12-13 11:12
楼主上次那个《请教系统内存泄露》帖子，怎么处理的没有分享出来啊。以后时间长了，就没人帮你分析问题啦。 ...

回楼上，因没这个问题一直没有解决到——开始以为找到原因了，不过后来又被推翻了。现在还在跟进中。

1. 这个问题一看上去就很难搞啊。
   
2. 会不会是内存访问越界了，破坏了 slab的信息。
   
3. 不知道把崩溃时的内存dump下来，检查一下slab的各个结构的内容有没有帮助。
   
4. 以前碰到过 crash工具读不出dump文件的slab信息的情况，有高人说可能slab被破坏了。
   
5. 不知道什么情况比较容易导致这些内存污染的情况

复制代码

我现在就是按这个思路来检查代码，不过就是清楚哪些情况会导致这种问题，所以上来希望得到大家的指点。

daniel_11

也遇到过类似的问题，友情帮顶！

titer1

内存污染问题很难办的

titer1

利用 内核 命令行，学习了

独孤九贱

eexplorer 发表于 2012-12-13 16:35
对slub不太熟，但是这种general protection fault一般都是你的code 内存访问越界，破坏了slub数据结构，导致 ...

谢谢，现在就是这样做的，期待可以得到有用的信息。

testh

根据这个：
# [ 6400.456241] Call Trace:
# [ 6400.456241]  <IRQ>
# [ 6400.456241]  [<ffffffff815f9a31>] __alloc_skb+0x41/0x230
# [ 6400.456241]  [<ffffffff815fa08f>] __netdev_alloc_skb+0x1f/0x40
# [ 6400.456241]  [<ffffffffa0041b0f>] e1000_alloc_rx_buffers+0x1cf/0x2d0 [e1000e]
找到__alloc_skb这个模块，应该是*.o的格式吧，然后objdump 反汇编看对应在源码的哪里

这个oops可以随心所欲的让他出来吗?如果可以的话可以使用jprobe和kprobe查看一下调用__alloc_skb时的参数，看看有没有帮助?