Linux內(nèi)核的死鎖檢測工具—Lockdep的使用案例
1.前言
死鎖是指兩個或多個進(jìn)程因爭奪資源而造成的互相等待的現(xiàn)象，如進(jìn)程A需要資源X，進(jìn)程B需要資源Y，而雙方都掌握對方所需要的資源，且都不釋放，這會導(dǎo)致死鎖。
在內(nèi)核開發(fā)中，時常要考慮并發(fā)設(shè)計，即使采用正確的編程思路，也不可能避免會發(fā)生死鎖。在Linux內(nèi)核中，常見的死鎖有如下兩種：
遞歸死鎖：如在中斷延遲操作中使用了鎖，和外面的鎖構(gòu)成了遞歸死鎖。 AB-BA死鎖：多個鎖因處理不當(dāng)而引發(fā)死鎖，多個內(nèi)核路徑上的鎖處理順序不一致也會導(dǎo)致死鎖。 Linux內(nèi)核在2006年引入了死鎖調(diào)試模塊lockdep，lockdep會跟蹤每個鎖的自身狀態(tài)和各個鎖之間的依賴關(guān)系，經(jīng)過一系列的驗(yàn)證規(guī)則來確保鎖之間依賴關(guān)系是正確。
2.配置內(nèi)核
要在Linux內(nèi)核中使用lockdep功能，需要打開CONFIG_DEBUG_LOCKDEP選項(xiàng)：
CONFIG_LOCK_STAT=y CONFIG_PROVE_LOCKING=y CONFIG_DEBUG_LOCKDEP=y
在proc目錄下會有l(wèi)ockdep、lockdep_chains和lockdep_stats三個文件節(jié)點(diǎn)，這說明lockdep模塊已經(jīng)生效：
然后重新編譯內(nèi)核，更換內(nèi)核重啟系統(tǒng)。
3.簡單的AB-BA死鎖案例
下面舉一個簡單的AB-BA死鎖的例子：
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kernel.h>
static DEFINE_SPINLOCK(hack_spinA);
static DEFINE_SPINLOCK(hack_spinB);
void hack_spinAB(void)
{
printk("hack_lockdep:A->B\n");
spin_lock(&hack_spinA);
spin_lock(&hack_spinB);
}
void hack_spinBA(void)
{
printk("hack_lockdep:B->A\n");
spin_lock(&hack_spinB);
}
static int __init lockdep_test_init(void)
{
printk("figo:my lockdep module init\n");
hack_spinAB();
hack_spinBA();
return 0;
}
static void __exit lockdep_test_exit(void)
{
printk("goodbye\n");
}
module_init(lockdep_test_init);
module_exit(lockdep_test_exit);
MODULE_LICENSE("GPL");
上述代碼初始化了兩個自旋鎖，其中hack_spinAB()函數(shù)分別申請了hack_spinA鎖和hack_spinB鎖，hack_spinBA()函數(shù)要申請hack_spinB鎖。因?yàn)閯偛沛ihack_spinB已經(jīng)被成功獲取且還沒有釋放，所以它會一直等待，而且它也被鎖在hack_spinA的臨界區(qū)里。
現(xiàn)象
[root@imx6ull:~]# insmod lockdep_test.ko
[ 437.981262] figo:my lockdep module init
[ 437.985145] hack_lockdep:A->B
[ 437.989054] hack_lockdep:B->A
[ 437.992304]
[ 437.993819] =============================================
[ 437.999229] [ INFO: possible recursive locking detected ]
[ 438.004641] 4.9.88 #2 Tainted: G O
[ 438.009180] ---------------------------------------------
[ 438.014589] insmod/367 is trying to acquire lock:
[ 438.019303] (hack_spinB){+.+...}, at: [<7f00a030>] lockdep_test_init+0x30/0x3c [lockdep_test]
[ 438.028006] but task is already holding lock:
[ 438.032547] (hack_spinB){+.+...}, at: [<7f008038>] hack_spinAB+0x38/0x3c [lockdep_test]
[ 438.040715] other info that might help us debug this:
[ 438.045950] Possible unsafe locking scenario:
[ 438.045950]
[ 438.051883] CPU0
[ 438.054337] ----
[ 438.056790] lock(hack_spinB);
[ 438.059975] lock(hack_spinB);
[ 438.063160]
[ 438.063160] *** DEADLOCK ***
[ 438.063160]
[ 438.069094] May be due to missing lock nesting notation
[ 438.069094]
[ 438.075896] 2 locks held by insmod/367:
[ 438.079740] #0: (hack_spinA){+.+...}, at: [<7f008030>] hack_spinAB+0x30/0x3c [lockdep_test]
[ 438.088358] #1: (hack_spinB){+.+...}, at: [<7f008038>] hack_spinAB+0x38/0x3c [lockdep_test]
[ 438.096977]
[ 438.096977] stack backtrace:
[ 438.101352] CPU: 0 PID: 367 Comm: insmod Tainted: G O 4.9.88 #2
[ 438.108410] Hardware name: Freescale i.MX6 UltraLite (Device Tree)
[ 438.114628] [<801136cc>] (unwind_backtrace) from [<8010e78c>] (show_stack+0x20/0x24)
[ 438.122396] [<8010e78c>] (show_stack) from [<804ccc34>] (dump_stack+0xa0/0xcc)
[ 438.129646] [<804ccc34>] (dump_stack) from [<8018f020>] (__lock_acquire+0x8bc/0x1d4c)
[ 438.137502] [<8018f020>] (__lock_acquire) from [<80190b78>] (lock_acquire+0xf4/0x2f8)
[ 438.145358] [<80190b78>] (lock_acquire) from [<80c94a0c>] (_raw_spin_lock+0x4c/0x84)
[ 438.153129] [<80c94a0c>] (_raw_spin_lock) from [<7f00a030>] (lockdep_test_init+0x30/0x3c [lockdep_test])
[ 438.162638] [<7f00a030>] (lockdep_test_init [lockdep_test]) from [<80102004>] (do_one_initcall+0x54/0x184)
[ 438.172315] [<80102004>] (do_one_initcall) from [<80229624>] (do_init_module+0x74/0x1f8)
[ 438.180431] [<80229624>] (do_init_module) from [<801dac54>] (load_module+0x201c/0x279c)
[ 438.188461] [<801dac54>] (load_module) from [<801db648>] (SyS_finit_module+0xc4/0xfc)
[ 438.196317] [<801db648>] (SyS_finit_module) from [<80109680>] (ret_fast_syscall+0x0/0x1c)
提示信息顯示：嘗試獲取hack_spinB鎖，但是該鎖已經(jīng)在函數(shù)hack_spinAB中被鎖定： 
lockdep已經(jīng)很清晰地顯示了死鎖發(fā)生的路徑和發(fā)生時函數(shù)調(diào)用的棧信息，根據(jù)這些信息可以很快速地定位問題和解決問題。
4.實(shí)際項(xiàng)目中的死鎖
下面的例子要復(fù)雜一些，這是從實(shí)際項(xiàng)目中抽取出來的死鎖，更具有代表性。
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/kthread.h>
#include <linux/freezer.h>
#include <linux/delay.h>
static DEFINE_MUTEX(mutex_a);
static struct delayed_work delay_task;
static void lockdep_timefunc(unsigned long);
static DEFINE_TIMER(lockdep_timer, lockdep_timefunc, 0, 0);
static void lockdep_timefunc(unsigned long dummy)
{
schedule_delayed_work(&delay_task, 10);
mod_timer(&lockdep_timer, jiffies + msecs_to_jiffies(100));
}
static void lockdep_test_work(struct work_struct *work)
{
mutex_lock(&mutex_a);
mdelay(300);//處理一些事情，這里用mdelay替代
mutex_unlock(&mutex_a);
}
static int lockdep_thread(void *nothing)
{
set_freezable();//清除當(dāng)前線程標(biāo)志flags中的PF_NOFREEZE位，表示當(dāng)前線程能進(jìn)入掛起或休眠狀態(tài)。
set_user_nice(current, 0);
while(!kthread_should_stop()){
mdelay(500);//處理一些事情，這里用mdelay替代
//遇到某些特殊情況，需要取消delay_task
mutex_lock(&mutex_a);
cancel_delayed_work_sync(&delay_task);
mutex_unlock(&mutex_a);
}
return 0;
}
static int __init lockdep_test_init(void)
{
printk("figo:my lockdep module init\n");
struct task_struct *lock_thread;
/*創(chuàng)建一個線程來處理某些事情*/
lock_thread = kthread_run(lockdep_thread, NULL, "lockdep_test");
/*創(chuàng)建一個延遲的工作隊(duì)列*/
INIT_DELAYED_WORK(&delay_task, lockdep_test_work);
/*創(chuàng)建一個定時器來模擬某些異步事件，如中斷等*/
lockdep_timer.expires = jiffies + msecs_to_jiffies(500);
add_timer(&lockdep_timer);
return 0;
}
static void __exit lockdep_test_exit(void)
{
printk("goodbye\n");
}
MODULE_LICENSE("GPL");
module_init(lockdep_test_init);
module_exit(lockdep_test_exit);
首先創(chuàng)建一個lockdep_thread內(nèi)核線程，用于周期性地處理某些事情，然后創(chuàng)建一個名為lockdep_test_worker的工作隊(duì)列來處理一些類似于中斷下半部的延遲操作，最后使用一個定時器來模擬某些異步事件（如中斷）。
在lockdep_thread內(nèi)核線程中，某些特殊情況下常常需要取消工作隊(duì)列。代碼中首先申請了一個mutex_a互斥鎖，然后調(diào)用cancel_delayed_work_sync()函數(shù)取消工作隊(duì)列。另外，定時器定時地調(diào)度工作隊(duì)列，并在回調(diào)函數(shù)lockdep_test_worker()函數(shù)中申請mutex_a互斥鎖。
以上便是該例子的調(diào)用場景，下面是運(yùn)行時捕捉到死鎖信息：
[root@imx6ull:~]# insmod lockdep_test.ko
[ 370.477536] figo:my lockdep module init
[root@imx6ull:~]# [ 371.124433]
[ 371.125970] ======================================================
[ 371.132162] [ INFO: possible circular locking dependency detected ]
[ 371.138445] 4.9.88 #2 Tainted: G O
[ 371.142987] -------------------------------------------------------
[ 371.149265] kworker/0:2/104 is trying to acquire lock:
[ 371.154414] (mutex_a){+.+...}, at: [<7f004078>] lockdep_test_work+0x24/0x58 [lockdep_test]
[ 371.162852] but task is already holding lock:
[ 371.167392] ((&(&delay_task)->work)){+.+...}, at: [<80157104>] process_one_work+0x1ec/0x8bc
[ 371.175912] which lock already depends on the new lock.
[ 371.175912]
[ 371.182799]
[ 371.182799] the existing dependency chain (in reverse order) is:
[ 371.190291]
-> #1 ((&(&delay_task)->work)){+.+...}:
[ 371.195432] flush_work+0x4c/0x278
[ 371.199371] __cancel_work_timer+0xa8/0x1d0
[ 371.204088] cancel_delayed_work_sync+0x1c/0x20
[ 371.209157] lockdep_thread+0x84/0xa4 [lockdep_test]
[ 371.214658] kthread+0x120/0x124
[ 371.218423] ret_from_fork+0x14/0x38
[ 371.222529]
-> #0 (mutex_a){+.+...}:
[ 371.226374] lock_acquire+0xf4/0x2f8
[ 371.230487] mutex_lock_nested+0x70/0x4bc
[ 371.235036] lockdep_test_work+0x24/0x58 [lockdep_test]
[ 371.240797] process_one_work+0x2b0/0x8bc
[ 371.245342] worker_thread+0x68/0x5c4
[ 371.249538] kthread+0x120/0x124
[ 371.253301] ret_from_fork+0x14/0x38
[ 371.257407]
[ 371.257407] other info that might help us debug this:
[ 371.257407]
[ 371.265424] Possible unsafe locking scenario:
[ 371.265424]
[ 371.271353] CPU0 CPU1
[ 371.275891] ---- ----
[ 371.280428] lock((&(&delay_task)->work));
[ 371.284656] lock(mutex_a);
[ 371.290098] lock((&(&delay_task)->work));
[ 371.296843] lock(mutex_a);
[ 371.299768]
[ 371.299768] *** DEADLOCK ***
[ 371.299768]
[ 371.305704] 2 locks held by kworker/0:2/104:
[ 371.309981] #0: ("events"){.+.+.+}, at: [<80157104>] process_one_work+0x1ec/0x8bc
[ 371.317729] #1: ((&(&delay_task)->work)){+.+...}, at: [<80157104>] process_one_work+0x1ec/0x8bc
[ 371.326690]
[ 371.326690] stack backtrace:
[ 371.331066] CPU: 0 PID: 104 Comm: kworker/0:2 Tainted: G O 4.9.88 #2
[ 371.338558] Hardware name: Freescale i.MX6 UltraLite (Device Tree)
[ 371.344760] Workqueue: events lockdep_test_work [lockdep_test]
[ 371.350643] [<801136cc>] (unwind_backtrace) from [<8010e78c>] (show_stack+0x20/0x24)
[ 371.358409] [<8010e78c>] (show_stack) from [<804ccc34>] (dump_stack+0xa0/0xcc)
[ 371.365659] [<804ccc34>] (dump_stack) from [<8018c6e4>] (print_circular_bug+0x208/0x320)
[ 371.373774] [<8018c6e4>] (print_circular_bug) from [<801900a0>] (__lock_acquire+0x193c/0x1d4c)
[ 371.382408] [<801900a0>] (__lock_acquire) from [<80190b78>] (lock_acquire+0xf4/0x2f8)
[ 371.390259] [<80190b78>] (lock_acquire) from [<80c8fda0>] (mutex_lock_nested+0x70/0x4bc)
[ 371.398373] [<80c8fda0>] (mutex_lock_nested) from [<7f004078>] (lockdep_test_work+0x24/0x58 [lockdep_test])
[ 371.408140] [<7f004078>] (lockdep_test_work [lockdep_test]) from [<801571c8>] (process_one_work+0x2b0/0x8bc)
[ 371.417988] [<801571c8>] (process_one_work) from [<8015783c>] (worker_thread+0x68/0x5c4)
[ 371.426099] [<8015783c>] (worker_thread) from [<8015e6c8>] (kthread+0x120/0x124)
[ 371.433516] [<8015e6c8>] (kthread) from [<8010971c>] (ret_from_fork+0x14/0x38)
lockdep信息首先提示可能出現(xiàn)遞歸死鎖"possible circular locking dependency detected"，然后提示"kworker/0:2/104"線程嘗試獲取mutex_a互斥鎖，但是該鎖已經(jīng)被其他進(jìn)程持有，持有該鎖的進(jìn)程在&delay_task->work里。
接下來的函數(shù)調(diào)用棧顯示上述嘗試獲取mutex_a鎖的調(diào)用路徑。兩個路徑如下：
（1）內(nèi)核線程lockdep_thread首先成功獲取了mutex_a互斥鎖，然后調(diào)用cancel_delayed_work_sync()函數(shù)取消kworker。注意，cancel_delayed_work_sync()函數(shù)會調(diào)用flush操作并等待所有的kworker回調(diào)函數(shù)執(zhí)行完，然后才會調(diào)用mutex_unlock(&mutex_a)釋放該鎖。
（2）kworker回調(diào)函數(shù)lockdep_test_worker()首先會嘗試獲取mutex_a互斥鎖。注意，剛才內(nèi)核線程lockdep_thread已經(jīng)獲取了mutex_a互斥鎖，并且一直在等待當(dāng)前kworker回調(diào)函數(shù)執(zhí)行完，所以死鎖發(fā)生了。
下面是該死鎖場景的CPU調(diào)用關(guān)系：
| CPU0 | CPU1 |
|---|---|
| 內(nèi)核線程lockdep_thread lock(mutex_a) cancel_delayed_work_sync() 等待worker執(zhí)行完成 | delay worker回調(diào)函數(shù) lock(mutex_a);嘗試獲取鎖 |
5.總結(jié)
文章主要介紹了Linux內(nèi)核中的死鎖問題,包括死鎖的類型（遞歸死鎖和AB-BA死鎖）、lockdep模塊的使用方法以及實(shí)際項(xiàng)目中的死鎖案例,通過lockdep模塊,可以有效地跟蹤和調(diào)試死鎖問題,幫助開發(fā)者快速定位和解決問題
到此這篇關(guān)于Linux內(nèi)核的死鎖檢測工具—Lockdep的使用案例的文章就介紹到這了,更多相關(guān)Linux內(nèi)核死鎖Lockdep內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
如何確保Apache?Flink流處理的數(shù)據(jù)一致性和可靠性
Apache?Flink通過其先進(jìn)的狀態(tài)管理、檢查點(diǎn)機(jī)制、時間語義和容錯策略,確保了在流處理中的高數(shù)據(jù)一致性和可靠性,本文詳細(xì)介紹了Flink中保證數(shù)據(jù)一致性和可靠性的機(jī)制,感興趣的朋友一起看看吧2024-08-08
Linux內(nèi)核宏container_of的深度剖析
今天小編就為大家分享一篇關(guān)于Linux內(nèi)核宏container_of的深度剖析，小編覺得內(nèi)容挺不錯的，現(xiàn)在分享給大家，具有很好的參考價值，需要的朋友一起跟隨小編來看看吧2019-02-02
關(guān)于VPS內(nèi)存不足的一些說明和解決辦法
關(guān)于VPS內(nèi)存不足的一些說明和解決辦法，需要的朋友可以參考下。2011-11-11
這篇文章主要介紹了Linux中OpenSSL命令的應(yīng)用場景,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-02-02
在Linux環(huán)境中安裝Kafka需要下載對應(yīng)版本的資源包,并安裝配置Zookeeper,此教程以kafka_2.12-2.5.1版本和apache-zookeeper-3.6.1為例,詳細(xì)介紹了單體及集群環(huán)境下的安裝步驟、配置修改、啟動驗(yàn)證以及Kerberos認(rèn)證配置,同時提供了kafka常用命令和注意事項(xiàng),適合初學(xué)者參考2024-10-10
Linux XAMPP下啟用WordPress的自定義文件名(偽靜態(tài))功能
這篇文章主要介紹了Linux XAMPP下啟用WordPress的自定義文件名(偽靜態(tài))功能的相關(guān)資料,需要的朋友可以參考下2016-12-12
這篇文章主要為大家詳細(xì)介紹了linux下dhcp服務(wù)的配置教程，具有一定的參考價值，感興趣的小伙伴們可以參考一下2017-04-04
今天小編就為大家分享一篇Linux下指定源ip進(jìn)行ping操作的方法，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧2018-06-06
本篇文章主要介紹了CentOS7下如何配置ip forward(虛擬路由器)，非常具有實(shí)用價值，需要的朋友可以參考下2017-09-09
linux新文件權(quán)限設(shè)置之umask的深入理解
這篇文章主要給大家介紹了關(guān)于linux新文件權(quán)限設(shè)置之umask的相關(guān)資料，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面來一起學(xué)習(xí)學(xué)習(xí)吧2019-03-03