如何调试内核中的死锁问题

Question

我有一个错误的内核模块,我试图修复.基本上,当此模块运行时,它将导致其他任务挂起超过120秒.由于几乎所有挂起的任务都在等待mm-> mmap_sem或某些文件系统锁(i_node-> i_mutex)我怀疑它与此模块有关并不能获取mmap_sem锁和某些文件系统级别按顺序锁定(如inote-> i_mutex),这可能会导致一些死锁问题.由于我的模块不会尝试直接获取这些锁,我认为这是我调用的一些函数来抓住这些锁.现在我想弄清楚我的模块中哪些函数调用导致问题.

但是,由于以下原因,我很难调试它:

1. 我不确切知道挂起的任务试图抓住哪个锁.我得到了挂起任务的调用跟踪,并知道它挂起的位置.内核还给了我一些信息,例如:"automount/3115:0 :(&type-> i_mutex_dir_key#2){ - ..},在:[] real_lookup + 0x24/0xc5".但是,我想确切地知道任务保持哪个锁,以及它为了找出问题而确切地想要获取哪个锁.由于内核不提供函数调用的参数以及调用跟踪,因此我发现很难获得这些信息.

2. 我正在使用gdb和vmware来调试它,这允许我设置断点,步入函数等.但是,由于哪个任务以及该任务将在什么时候挂起是一种不确定的,我真的不知道在哪里设置断点和检查.如果我能以某种方式"附加"到内核报告被阻止超过120秒的任务,并得到一些有关它的信息,那将是很棒的.

所以我的问题如下:

1. 我可以在哪里获得调用跟踪中调用跟踪中函数的参数,以便确切地确定任务正在尝试抓取哪个锁.

2. 我是否可以使用gdb以某种方式"附加"到内核中的挂起任务？如果没有,我是否有办法至少检查代表该任务的数据结构？因为我很难检查内核中的所有全局数据结构.GDB总是抱怨"无法访问内存0x3200"或类似的东西.

3. 如果我可以打印出内核中的每个任务,它们当前持有什么锁,这也将非常有用.有办法吗？

非常感谢你!

Answer 1

让我尝试。1）尝试KGDB

2）你的意思是一个挂起的进程？ http://www.ibm.com/developerworks/aix/library/au-unix-strace.html

3）也许尝试 lsof 包。