我有一個有問題的內核模塊，我正在嘗試修復。基本上當這個模塊運行時，它會導致其他任務掛起超過120秒。由於幾乎所有掛起的任務都在等待mm-> mmap_sem或某些文件系統鎖（i_node-> i_mutex），我懷疑它與這個模塊有關，並不會獲取mmap_sem鎖和一些文件系統級鎖定（如inote-> i_mutex），這可能會導致一些死鎖問題。由於我的模塊不會直接抓住這些鎖，所以我認爲這是我調用的一些函數來抓住這些鎖。現在我正在試圖找出模塊中哪些函數調用導致問題。如何調試內核中的死鎖問題
不過，我有一個很難調試它，原因如下：
我並不確切，其鎖定掛起的任務就是試圖抓住知道。我得到了掛起任務的呼叫追蹤，並知道它在什麼地方掛起。內核還給我提供了一些信息，如： 「1鎖佔用自動掛載/ 3115： 0：（& type-> i_mutex_dir_key＃2）{ - ..}，在：[] real_lookup + 0x24/0xc5。 但是，我想知道確切地知道哪個鎖佔用任何鎖，並且確切知道爲了找出問題而嘗試獲取哪個鎖。由於內核不提供函數調用的參數以及調用跟蹤，我發現這些信息很難獲得。
我正在使用gdb和vmware來調試這個，它允許我設置斷點，進入一個函數等。但是，哪個任務以及該任務將掛起的點是不確定的，我不知道應該在哪裏設置斷點並進行檢查。如果我能以某種方式「附加」被報告被阻塞的內核超過120秒的任務並獲得關於它的一些信息，那將是非常好的。
所以我的問題如下：
我在哪裏可以得到，與呼叫跟蹤，在呼叫跟蹤功能的參數一起，爲了到底是哪鎖定弄清楚一項任務試圖抓住。
是否有可能使用gdb以某種方式「附加」到內核中的掛起任務？如果不是，有什麼方法可以讓我至少檢查表示該任務的數據結構？因爲我很難在內核中檢查所有的全局數據結構。 GDB總是抱怨「無法訪問內存0x3200」或類似的東西。
如果我能打印出內核中的每個任務，它們當前擁有什麼鎖定，這也會非常有幫助。有沒有辦法做到這一點？
非常感謝！