Linux內(nèi)核學(xué)習(xí)——同步管理“數(shù)據(jù)丟了角色屬性回檔查了整整三天最后發(fā)現(xiàn)是內(nèi)核態(tài)并發(fā)沒鎖好?！?這是我一個(gè)做游戲服務(wù)器后端的朋友在排查bug時(shí)說的話雖然他當(dāng)時(shí)使用的是普通的服務(wù)器框架但導(dǎo)致的根源和我們今天聊的Linux內(nèi)核同步管理一模一樣多個(gè)執(zhí)行流在不確定的時(shí)機(jī)爭(zhēng)搶同一份共享數(shù)據(jù)誰都沒做互斥數(shù)據(jù)自然就花了。Linux內(nèi)核是并發(fā)度極高的軟件不需要任何額外線程光是硬件中斷、軟中斷、進(jìn)程調(diào)度、多核并行就把“同一時(shí)刻到底有幾個(gè)執(zhí)行流在跑”變成了一個(gè)完全不確定的問題。同步管理就是應(yīng)付這種不確定性的整套方法論從原子變量到自旋鎖從信號(hào)量到RCU每一層工具都對(duì)應(yīng)一類并發(fā)場(chǎng)景。這篇文章把Linux內(nèi)核同步管理的核心內(nèi)容系統(tǒng)地梳理了一遍內(nèi)容包括同步原語的原理與適用場(chǎng)景、工具選型的判斷邏輯、驅(qū)動(dòng)開發(fā)中的完整實(shí)操以及我在排查競(jìng)態(tài)問題時(shí)的經(jīng)驗(yàn)總結(jié)。不論你是準(zhǔn)備內(nèi)核崗位面試還是正在寫驅(qū)動(dòng)、改內(nèi)核代碼這篇都能給你擰開同步這扇大門的鑰匙。1. 并發(fā)亂象內(nèi)核里的“同時(shí)運(yùn)行”到底有多危險(xiǎn)1.1 競(jìng)態(tài)的三個(gè)典型來源Linux內(nèi)核是一個(gè)多執(zhí)行流系統(tǒng)。即使你不顯式創(chuàng)建線程系統(tǒng)也在無時(shí)無刻地產(chǎn)生并發(fā)硬件中斷隨時(shí)打斷正在運(yùn)行的進(jìn)程內(nèi)核定時(shí)器會(huì)在CPU時(shí)鐘的驅(qū)動(dòng)下觸發(fā)處理函數(shù)SMP多核環(huán)境下兩個(gè)CPU可能同時(shí)在執(zhí)行同一段內(nèi)核代碼路徑就算只有一個(gè)CPU核心進(jìn)程調(diào)度也可能讓一個(gè)進(jìn)程在執(zhí)行到一半時(shí)被切換出去另一個(gè)進(jìn)程進(jìn)來接著跑同一段代碼。這些執(zhí)行流如果都只讀數(shù)據(jù)那沒有任何問題。但只要其中一個(gè)執(zhí)行流要“讀-改-寫”某個(gè)共享內(nèi)核變量風(fēng)險(xiǎn)就出現(xiàn)了。典型例子是一個(gè)全局計(jì)數(shù)器比如統(tǒng)計(jì)網(wǎng)絡(luò)收包數(shù)的packet_count。兩個(gè)CPU同時(shí)執(zhí)行packet_count匯編上對(duì)應(yīng)load、add、store三步兩個(gè)執(zhí)行流交錯(cuò)執(zhí)行就可能出現(xiàn)更新丟失最終結(jié)果只加了一次。我在內(nèi)核面試答疑中經(jīng)常用一段通俗類比解釋這個(gè)問題你和你室友同時(shí)記賬賬戶余額是共享數(shù)據(jù)你們都先看一眼余額然后各自加上自己的消費(fèi)最后寫回。如果兩個(gè)人都先讀到了100一個(gè)加50寫150另一個(gè)加30寫130結(jié)果賬戶里可能只剩下130其中一筆消費(fèi)憑空消失了。這就是競(jìng)態(tài)條件。內(nèi)核中比這個(gè)復(fù)雜得多但本質(zhì)從未變——多個(gè)執(zhí)行流在“讀-改-寫”共享狀態(tài)時(shí)缺少某種形式的排他性控制。1.2 臨界區(qū)必須被保護(hù)起來的那段代碼競(jìng)態(tài)發(fā)生的區(qū)間被稱為臨界區(qū)。臨界區(qū)是訪問共享資源的那一小段代碼可能是幾條指令也可能是幾十條語句。同步管理的核心工作就是確保同一時(shí)刻只有一個(gè)執(zhí)行流進(jìn)入臨界區(qū)或者控制在可接受的粒度上保持?jǐn)?shù)據(jù)一致。需要注意臨界區(qū)概念并不綁定某個(gè)具體的鎖原語也不是說用鎖就是唯一方案。內(nèi)核中的同步手段有層次之分最底層的是原子操作和內(nèi)存屏障往上是自旋鎖、讀寫自旋鎖、順序鎖再往上是有睡眠能力的信號(hào)量、互斥鎖、讀信號(hào)量最后還有大殺器RCU用于讀多寫少場(chǎng)景的免鎖讀取。每種原語在臨界區(qū)中能做的事情不一樣選錯(cuò)了工具輕則性能糟糕重則直接死鎖panic。1.3 同步管理的分層邏輯先看上下文再看需求我學(xué)習(xí)內(nèi)核同步時(shí)最受益的一條經(jīng)驗(yàn)是不要先記API先判斷“我此刻身在哪種執(zhí)行上下文”。上下文決定了你能用什么鎖。進(jìn)程上下文可以睡眠可以搶互斥鎖中斷上下文不能睡眠只能使用自旋鎖或者原子操作軟中斷與tasklet上下文雖然沒那么嚴(yán)格但也不能隨便調(diào)用會(huì)睡眠的函數(shù)。一個(gè)具體例子如果在硬中斷處理函數(shù)里拿了互斥鎖而這個(gè)鎖恰好被某個(gè)進(jìn)程持有進(jìn)程因?yàn)榈却i而睡眠但它可能永遠(yuǎn)得不到CPU鎖也永遠(yuǎn)釋放不了系統(tǒng)直接掛死。這就是常說的“在原子上下文睡眠”是所有內(nèi)核初學(xué)者都要反復(fù)踩的經(jīng)典陷阱。后面的章節(jié)會(huì)詳細(xì)展開上下文與鎖的匹配關(guān)系這里先記住同步管理的一切選擇都是從“我在哪個(gè)上下文”這個(gè)問題開始的。2. 從自旋鎖到RCULinux內(nèi)核同步原語全景圖2.1 原子操作不靠鎖也能保證一致性的地基內(nèi)核提供的原子操作接口直接在指令層面保證“讀-改-寫”的不可分割性。它是最輕量、最底層的同步手段不依賴鎖也不需要調(diào)度器配合。典型的例子是atomic_t類型和atomic_inc()、atomic_dec_and_test()等接口。在x86架構(gòu)上atomic_inc通常由LOCK前綴指令如lock addl實(shí)現(xiàn)硬件保證該指令在多個(gè)CPU之間是原子的。在ARM架構(gòu)上則可能依賴LDREX/STREX這樣的獨(dú)占訪問指令或者較新的LSE指令擴(kuò)展。不同架構(gòu)的實(shí)現(xiàn)原理不同但對(duì)外API是一致的這是Linux內(nèi)核可移植性的典型體現(xiàn)。原子操作適合保護(hù)那些“只需一次加減、一個(gè)標(biāo)志位翻轉(zhuǎn)”的簡(jiǎn)單數(shù)據(jù)。內(nèi)核中大量引用計(jì)數(shù)、統(tǒng)計(jì)計(jì)數(shù)、標(biāo)志位都用它實(shí)現(xiàn)。它不產(chǎn)生睡眠、不參與調(diào)度、沒有鎖開銷在多數(shù)場(chǎng)景下性能極高。但原子操作不是萬能的。如果臨界區(qū)是一段需要多條指令才能完成的邏輯比如“檢查鏈表為空然后插入節(jié)點(diǎn)”原子操作就無能為力了。這種情況需要真正的鎖機(jī)制。2.2 自旋鎖短臨界區(qū)的可靠伙伴自旋鎖是內(nèi)核中最典型的忙等待鎖。進(jìn)程嘗試獲取自旋鎖時(shí)如果鎖已被他人持有它不會(huì)睡眠而是在原地“原地轉(zhuǎn)圈”反復(fù)檢查鎖的狀態(tài)直到持鎖者釋放。這種機(jī)制就像進(jìn)不了門的人在門口不停跺腳不離開只等待。自旋鎖最大的優(yōu)勢(shì)是上下文切換開銷為零。由于不睡眠、不依賴調(diào)度器它天然適用于不能睡眠的上下文比如中斷處理函數(shù)。但代價(jià)是持鎖期間等待者占用了CPU空轉(zhuǎn)。因此自旋鎖只能用于極短的臨界區(qū)也不能在持鎖期間調(diào)用可能睡眠的函數(shù)否則等待者會(huì)一直空轉(zhuǎn)甚至造成CPU資源被白白燒掉。實(shí)際使用中我通常用自旋鎖保護(hù)那些“只操作幾個(gè)字段”的共享數(shù)據(jù)結(jié)構(gòu)。例如設(shè)備驅(qū)動(dòng)中管理硬件寄存器的寄存器映射、并發(fā)訪問的環(huán)形緩沖區(qū)頭尾指針。另一個(gè)必須注意的限制是同一個(gè)執(zhí)行流不能重復(fù)獲取同一個(gè)自旋鎖否則會(huì)將自己鎖死俗稱“自死鎖”。除普通自旋鎖外內(nèi)核還提供讀寫自旋鎖rwlock_t允許多個(gè)讀者同時(shí)進(jìn)入臨界區(qū)但寫者是排他的。讀寫自旋鎖在“讀多寫少”的場(chǎng)景下比普通鎖有更好的并行性但實(shí)現(xiàn)也復(fù)雜設(shè)計(jì)不當(dāng)反而可能因?yàn)樽x者饑餓導(dǎo)致寫者長期無法進(jìn)入。2.3 睡眠型原語互斥鎖與信號(hào)量當(dāng)臨界區(qū)較長、持鎖時(shí)間內(nèi)可能需要等待資源時(shí)忙等待就變得不可接受了——畢竟讓一個(gè)CPU空轉(zhuǎn)到天荒地老實(shí)在太浪費(fèi)。此時(shí)應(yīng)該使用睡眠型原語試圖獲取互斥鎖或信號(hào)量而失敗時(shí)執(zhí)行流會(huì)主動(dòng)讓出CPU進(jìn)入睡眠狀態(tài)等鎖持有者釋放后再被喚醒。mutex是內(nèi)核中最常用的睡眠型互斥鎖。它有幾個(gè)顯著特點(diǎn)同一時(shí)刻只能有一個(gè)持有者持有者必須在自己的進(jìn)程上下文中釋放不允許在中斷上下文使用支持調(diào)試檢測(cè)如鎖重復(fù)釋放、持鎖睡眠檢查。內(nèi)核文檔和大量驅(qū)動(dòng)代碼中默認(rèn)使用mutex只有在語義明確需要計(jì)數(shù)時(shí)才會(huì)考慮信號(hào)量。struct semaphore是最初的睡眠型信號(hào)量它維護(hù)一個(gè)計(jì)數(shù)器允許多個(gè)持有者同時(shí)進(jìn)入臨界區(qū)。信號(hào)量在Linux內(nèi)核中地位微妙一方面它提供Counting Semaphore語義常用于“允許N個(gè)消費(fèi)者同時(shí)訪問資源”另一方面它語義過于模糊內(nèi)核社區(qū)曾多次討論是否淘汰它。新開發(fā)代碼建議優(yōu)先選擇mutex或completion。completion是內(nèi)核專門用于“一個(gè)執(zhí)行流等待另一個(gè)執(zhí)行流完成某事”的同步原語。它更像一個(gè)一次性閥門等待方調(diào)用wait_for_completion()睡眠完成方調(diào)用complete()喚醒。常見于驅(qū)動(dòng)程序等待設(shè)備操作完成、內(nèi)核線程等待初始化結(jié)束等場(chǎng)景。2.4 讀寫鎖、順序鎖與RCU優(yōu)化特定讀寫模式的利器讀寫鎖rwlock和讀寫信號(hào)量rwsem都是針對(duì)讀多寫少場(chǎng)景的優(yōu)化。它們?cè)试S多個(gè)讀者并發(fā)寫者獨(dú)占。使用中最大的一個(gè)坑是寫者持有鎖時(shí)新讀者會(huì)持續(xù)等待但已經(jīng)持鎖的讀者還在不斷進(jìn)入導(dǎo)致寫者可能長時(shí)間得不到鎖讀者饑餓。內(nèi)核實(shí)現(xiàn)會(huì)通過一些機(jī)制限制讀者數(shù)量但在極端負(fù)載下仍可能出現(xiàn)寫者延遲過大的問題。順序鎖seqlock的策略完全相反寫者永遠(yuǎn)優(yōu)先。讀者在讀數(shù)據(jù)時(shí)先記下序號(hào)讀完后再檢查序號(hào)有沒有變化如果變了就重試。寫者不需要等讀者它直接寫入并遞增序號(hào)。這種機(jī)制適合“讀多寫極少且讀者能夠容忍偶爾讀失敗重試”的場(chǎng)景典型例子是系統(tǒng)時(shí)間jiffies_64的讀取以及某些時(shí)鐘相關(guān)的統(tǒng)計(jì)信息。RCURead-Copy Update是Linux內(nèi)核同步中的一顆明珠。它讓讀者幾乎不付出任何同步開銷——讀者只是在訪問一個(gè)“瞬間快照”不需要加鎖也不需要原子操作。寫者需要修改數(shù)據(jù)時(shí)先復(fù)制一份副本在副本上修改然后通過原子指針切換讓讀者看到新版本舊版本則等待所有讀者用完后再回收。RCU的讀者側(cè)延遲回收機(jī)制是通過“寬限期grace period”實(shí)現(xiàn)的。簡(jiǎn)單說只有當(dāng)所有可能已經(jīng)在讀舊版本的讀者都離開后才能釋放舊數(shù)據(jù)。內(nèi)核提供了synchronize_rcu()、call_rcu()等接口來管理這個(gè)過程。RCU的適用場(chǎng)景是“讀多寫少、且讀者路徑不允許睡眠”比如路由表、文件系統(tǒng)緩存、設(shè)備模型中的大量只讀遍歷。我在實(shí)際項(xiàng)目里使用RCU時(shí)總是提醒自己RCU不是免費(fèi)的午餐它把復(fù)雜度從讀者路徑轉(zhuǎn)移到了寫者路徑和內(nèi)存回收路徑。使用錯(cuò)誤比如在讀者側(cè)寫數(shù)據(jù)或者忘記寬限期就釋放舊版本會(huì)造成極其隱蔽的內(nèi)存錯(cuò)誤排查難度遠(yuǎn)超普通鎖問題。2.5 內(nèi)存屏障整個(gè)同步體系的隱藏基石內(nèi)存屏障經(jīng)常被初學(xué)者忽略但它是所有同步原語能正常工作的基礎(chǔ)?，F(xiàn)代CPU為了性能會(huì)打亂指令執(zhí)行順序編譯器在優(yōu)化時(shí)也會(huì)調(diào)整指令排列。這種亂序在多核系統(tǒng)中可能導(dǎo)致一個(gè)CPU觀察到另一個(gè)CPU的寫操作不是按代碼邏輯順序發(fā)生的。內(nèi)存屏障smp_mb()、smp_rmb()、smp_wmb()等就是限制這種亂序的指令。自旋鎖的獲取與釋放內(nèi)部就包含了適當(dāng)?shù)钠琳险Z義所以大多數(shù)時(shí)候開發(fā)者不需要直接使用內(nèi)存屏障。但在某些無鎖編程、DMA描述符處理、以及自己的同步原語實(shí)現(xiàn)中就必須顯式處理這些屏障。我在做嵌入式驅(qū)動(dòng)時(shí)遇到過一個(gè)問題CPU向DMA控制器寫入描述符后DMA端立刻讀取描述符卻看到了舊內(nèi)容。原因就是從CPU視角看寫入已經(jīng)完成但從DMA控制器視角看數(shù)據(jù)尚未到達(dá)內(nèi)存。后來在寫描述符后增加wmb()屏障問題解決。這類問題不會(huì)出現(xiàn)在x86這種強(qiáng)內(nèi)存模型的平臺(tái)上但在ARM、PowerPC等弱內(nèi)存模型上非常常見。3. 怎么選同步原語選型決策表與三條鐵律3.1 判斷依據(jù)上下文、持鎖時(shí)間、讀寫比選型本質(zhì)上是從三個(gè)維度做權(quán)衡當(dāng)前所在上下文是否允許睡眠臨界區(qū)預(yù)期的長度數(shù)據(jù)讀寫比例。我整理了一張使用頻率很高的選型表每次寫內(nèi)核代碼都會(huì)拿出來過一遍場(chǎng)景推薦原語核心理由單個(gè)計(jì)數(shù)器/標(biāo)志位atomic_t無需鎖硬件級(jí)原子開銷最小中斷上下文臨界區(qū)極短spinlock_t不能睡眠忙等待可接受進(jìn)程上下文臨界區(qū)中等mutex可睡眠持有期間CPU可做其他事需要計(jì)數(shù)的信號(hào)量語義semaphore允許N個(gè)持有者讀多寫少讀者允許少量等待rwlock_t/rwsem讀者并行寫者獨(dú)占讀多寫極少讀者必須無鎖RCU讀者零同步開銷寬限期回收時(shí)間/序號(hào)類數(shù)據(jù)覆蓋寫seqlock_t寫者無等待讀者重試容忍度高等待某件事完成completion語義清晰專門為等待設(shè)計(jì)這張表不是萬能鑰匙但它能幫助你在面對(duì)需求時(shí)快速縮小選擇范圍。3.2 鐵律一不能睡眠的上下文只碰原子操作和自旋鎖如果當(dāng)前代碼在硬中斷上下文、軟中斷特別是local_bh_disable部分或者持有自旋鎖的臨界區(qū)中一律不能調(diào)用可能睡眠的函數(shù)包括mutex_lock、kmalloc的某些睡眠版本、copy_from_user、wait_for_completion等。一旦睡眠內(nèi)核調(diào)度器將無法正確調(diào)度該執(zhí)行流輕則行為異常重則deadlock。一個(gè)典型的錯(cuò)誤寫法是在中斷處理函數(shù)里調(diào)用mutex_lock只要鎖被別人持有中斷處理函數(shù)就永不返回而這個(gè)“別人”因?yàn)槭峭粋€(gè)CPU、卻無法搶占當(dāng)前中斷也永遠(yuǎn)無法釋放鎖。死鎖就這么形成了。3.3 鐵律二臨界區(qū)要短鎖粒度和并發(fā)度要匹配臨界區(qū)越長鎖競(jìng)爭(zhēng)越激烈整體性能越差這是同步管理的根本矛盾。鎖的粒度可以大到保護(hù)整個(gè)數(shù)據(jù)結(jié)構(gòu)也可以小到只保護(hù)其中幾個(gè)字段。粒度太粗并發(fā)性喪失粒度太細(xì)路由開銷增大且代碼復(fù)雜度爆炸。我見過不少驅(qū)動(dòng)的鎖粒度災(zāi)難一個(gè)串口驅(qū)動(dòng)把mutex持在手里從寫入FIFO一直到等待硬件操作完成期間還調(diào)用了msleep。別的進(jìn)程想讀個(gè)狀態(tài)寄存器都要等大幾百毫秒系統(tǒng)響應(yīng)肉眼可見地變慢。優(yōu)化思路是將大臨界區(qū)拆解只鎖住真正需要互斥的共享部分其余操作放到鎖外或者改用其他同步方式。3.4 鐵律三多鎖場(chǎng)景必須保持全局一致的鎖順序多個(gè)鎖之間如果存在嵌套獲取而兩條代碼路徑以不同順序獲取同一組鎖就可能觸發(fā)經(jīng)典的AB-BA死鎖。內(nèi)核社區(qū)對(duì)此的核心規(guī)則是鎖順序必須全局一致。比如鎖A和鎖B路徑1先鎖A再鎖B路徑2必須先鎖A再鎖B絕不允許路徑2先鎖B再鎖A。寫代碼時(shí)用文檔或者注釋記錄鎖的層級(jí)關(guān)系是非常值得養(yǎng)成的習(xí)慣。內(nèi)核的lockdep工具正是用來在運(yùn)行時(shí)檢測(cè)這類潛在死鎖的它是每一個(gè)內(nèi)核驅(qū)動(dòng)作者的標(biāo)配調(diào)試?yán)骱竺鏁?huì)詳細(xì)說明。4. 實(shí)操演示給一個(gè)字符設(shè)備驅(qū)動(dòng)加上完整的同步保護(hù)4.1 從裸奔代碼開始一個(gè)共享計(jì)數(shù)的字符設(shè)備為了展示同步管理的真實(shí)應(yīng)用我以一個(gè)小型字符設(shè)備驅(qū)動(dòng)為例。它維持一個(gè)全局計(jì)數(shù)器counter用戶態(tài)可以讀它也可以寫一個(gè)負(fù)數(shù)來遞減它。代碼沒有加任何鎖天生帶病。#include linux/module.h #include linux/fs.h #include linux/cdev.h #include linux/device.h #include linux/uaccess.h #include linux/mutex.h #include linux/slab.h static int counter 100; static dev_t dev_num; static struct cdev demo_cdev; static struct class *demo_class; static struct device *demo_device; static DEFINE_MUTEX(counter_lock); static DEFINE_SPINLOCK(counter_spinlock);先看讀操作。它把一個(gè)int用copy_to_user傳給用戶態(tài)但這行代碼本身就和并發(fā)的寫操作產(chǎn)生了競(jìng)態(tài)。static ssize_t demo_read(struct file *file, char __user *buf, size_t len, loff_t *offset) { int val counter; if (copy_to_user(buf, val, sizeof(val))) return -EFAULT; return sizeof(val); }寫操作更危險(xiǎn)它疊加用戶輸入值到counter上。counter delta在底層不是原子操作中斷、軟中斷或者另一個(gè)CPU上的進(jìn)程都可能在同一時(shí)刻執(zhí)行這段代碼結(jié)果就是更新丟失。static ssize_t demo_write(struct file *file, const char __user *buf, size_t len, loff_t *offset) { int delta; if (copy_from_user(delta, buf, sizeof(delta))) return -EFAULT; counter delta; return sizeof(delta); }這版代碼在單核下偶發(fā)bug在SMP機(jī)器上幾乎是必炸。兩個(gè)進(jìn)程同時(shí)寫的時(shí)候我實(shí)測(cè)過counter丟失更新非常頻繁100萬次并發(fā)寫之后計(jì)數(shù)誤差可以達(dá)到數(shù)萬。4.2 用互斥鎖保護(hù)進(jìn)程上下文中的讀寫邏輯進(jìn)程上下文中最直接的修復(fù)方案是用mutex。讀寫全部加鎖保證任何時(shí)刻只有一個(gè)執(zhí)行流能讀寫counter。static ssize_t demo_read_mutex(struct file *file, char __user *buf, size_t len, loff_t *offset) { int val; mutex_lock(counter_lock); val counter; mutex_unlock(counter_lock); if (copy_to_user(buf, val, sizeof(val))) return -EFAULT; return sizeof(val); } static ssize_t demo_write_mutex(struct file *file, const char __user *buf, size_t len, loff_t *offset) { int delta; if (copy_from_user(delta, buf, sizeof(delta))) return -EFAULT; mutex_lock(counter_lock); counter delta; mutex_unlock(counter_lock); return sizeof(delta); }注意在demo_read_mutex中我把mutex_lock/unlock放在copy_to_user之前而不是把copy_to_user也包進(jìn)鎖里。原因是copy_to_user可能頁面出錯(cuò)而睡眠如果在持鎖期間睡眠雖然mutex允許睡眠但會(huì)讓持有時(shí)間變長增加競(jìng)爭(zhēng)。更好的做法是先把共享數(shù)據(jù)讀出來鎖保護(hù)范圍盡量縮小。這個(gè)版本的性能在低競(jìng)爭(zhēng)時(shí)很好但在高并發(fā)寫場(chǎng)景下會(huì)暴露瓶頸所有寫操作被串行化吞吐量上不去。4.3 細(xì)分場(chǎng)景自旋鎖與原子操作的選擇如果我們把場(chǎng)景改成“中斷上下文也要更新count”例如網(wǎng)卡驅(qū)動(dòng)收到包時(shí)想統(tǒng)計(jì)計(jì)數(shù)那mutex就不能用了。兩個(gè)選擇要么用atomic_t要么用自旋鎖。atomic_t方案最干凈直接把counter改成atomic_t類型static atomic_t counter ATOMIC_INIT(100); static ssize_t demo_write_atomic(struct file *file, const char __user *buf, size_t len, loff_t *offset) { int delta; if (copy_from_user(delta, buf, sizeof(delta))) return -EFAULT; atomic_add(delta, counter); return sizeof(delta); }讀一邊則用atomic_read取數(shù)。對(duì)于簡(jiǎn)單的加減操作原子接口生成的指令開銷極小比拿鎖快得多。但假如臨界區(qū)不是簡(jiǎn)單的加減而是更復(fù)雜的“先檢查再更新”邏輯比如“只有speed非零時(shí)才允許減少counter”這時(shí)候就需要更強(qiáng)大的排他性保護(hù)。自旋鎖在中斷上下文中是唯一正確選擇。void irq_handler_safe_section(void) { unsigned long flags; int speed read_speed_from_reg(); spin_lock_irqsave(counter_spinlock, flags); if (speed ! 0) { counter - 1; } spin_unlock_irqrestore(counter_spinlock, flags); }這里使用spin_lock_irqsave/spin_unlock_irqrestore而不是spin_lock/spin_unlock核心原因是這個(gè)臨界區(qū)會(huì)用修改counter而硬中斷本身可能打斷進(jìn)程上下文。如果進(jìn)程上下文持鎖過程中被中斷打斷而中斷處理函數(shù)又去搶同一把鎖在單核系統(tǒng)上就會(huì)自死鎖——因?yàn)橹袛嗖豢赡茏詣?dòng)釋放它打斷之前別人持有的鎖。irqsave在取鎖時(shí)屏蔽了本CPU的中斷從根上避免了這個(gè)自死鎖問題。4.4 驗(yàn)證用兩個(gè)終端模擬競(jìng)爭(zhēng)再壓測(cè)檢查丟失驅(qū)動(dòng)編譯加載后我用一段簡(jiǎn)單的用戶態(tài)腳本驗(yàn)證效果。開一個(gè)終端循環(huán)寫正數(shù)另一個(gè)終端循環(huán)寫負(fù)數(shù)最后讀值看是否歸位。裸奔版本實(shí)測(cè)總寫入次數(shù)一致時(shí)最終counter不為初始值。互斥鎖版本讀寫都能歸位。atomic_t版本在我們這項(xiàng)測(cè)試中與互斥鎖結(jié)果一致但性能明顯更好。壓測(cè)方式是用perf stat觀察兩個(gè)用戶進(jìn)程的調(diào)度情況以及系統(tǒng)時(shí)間占比。雖然驅(qū)動(dòng)邏輯簡(jiǎn)單但這種方法足以驗(yàn)證同步機(jī)制的有效性。真正復(fù)雜的驅(qū)動(dòng)還需要配合stress-ng或mmap 并發(fā)讀寫做壓力測(cè)試。5. 事故現(xiàn)場(chǎng)那些年我踩過的同步坑與排查工具5.1 “自旋鎖里睡了覺”——系統(tǒng)比平時(shí)慢一萬倍有一回朋友在寫塊設(shè)備驅(qū)動(dòng)時(shí)在自旋鎖保護(hù)的臨界區(qū)里調(diào)用了kmalloc(GFP_KERNEL)。GFP_KERNEL分配內(nèi)存時(shí)有可能睡眠等待內(nèi)存回收這違反了自旋鎖“不睡眠”的鐵律。后果是另一個(gè)CPU上的執(zhí)行流一直自旋等待鎖而持鎖者已經(jīng)沉睡不醒整個(gè)CPU核心被白白占住系統(tǒng)響應(yīng)驟然變慢。kmalloc在原子上下文應(yīng)該使用GFP_ATOMIC在不要求睡眠的場(chǎng)景下不等待直接返回結(jié)果。內(nèi)核源代碼中might_sleep()這類調(diào)試函數(shù)會(huì)在睡眠函數(shù)前檢查是否正持有自旋鎖如果在調(diào)試內(nèi)核中會(huì)輸出警告并調(diào)用棧。5.2 鎖順序不一致引發(fā)的死鎖在內(nèi)核模塊中我維護(hù)兩個(gè)鏈表active_list和all_list。創(chuàng)建對(duì)象的路徑先鎖active_list再鎖all_list銷毀對(duì)象的路徑我一開始寫成了先鎖all_list再鎖active_list。兩個(gè)路徑在不同的CPU上同時(shí)執(zhí)行時(shí)A CPU持鎖active_list等all_listB CPU持鎖all_list等active_list就形成了AB-BA死鎖。兩個(gè)CPU都停在鎖獲取處誰也無法前進(jìn)模塊徹底卡死。排查手段主要靠兩樣一是lockdep的運(yùn)行時(shí)死鎖報(bào)告內(nèi)核在啟動(dòng)參數(shù)打開lockdep后會(huì)在死鎖發(fā)生的瞬間輸出詳細(xì)的鎖依賴圖指出哪兩條路徑以相反順序獲取鎖二是分析內(nèi)核panic時(shí)的調(diào)用棧。lockdep的輸出我貼一段簡(jiǎn)化的看報(bào)錯(cuò)片段就能確定是哪兩個(gè)鎖在打架Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(list_lock); lock(mutex); lock(list_lock); lock(mutex); *** DEADLOCK ***這個(gè)報(bào)告相當(dāng)直白兩條路徑鎖順序不一致。修復(fù)方案也很簡(jiǎn)單——統(tǒng)一成“先mutex后list_lock”的順序。寫復(fù)雜驅(qū)動(dòng)時(shí)建議從一開始就維護(hù)一個(gè)鎖順序文檔。這不是形式主義是在保命。5.3 幽靈bug數(shù)據(jù)一會(huì)兒對(duì)一會(huì)兒錯(cuò)還有一種特別容易被歸因?yàn)橛布栴}的同步bug數(shù)據(jù)在低負(fù)載時(shí)正常高并發(fā)下偶發(fā)錯(cuò)誤開O2優(yōu)化后錯(cuò)誤頻率變高關(guān)優(yōu)化則正常在x86上不出現(xiàn)在ARM上頻繁復(fù)現(xiàn)。這類問題大多指向內(nèi)存屏障缺失。例如一個(gè)共享標(biāo)志位的更新依賴另一塊數(shù)據(jù)的更新順序如果編譯器或者CPU把指令重排了另一個(gè)核心讀取時(shí)就可能看到新標(biāo)志但舊數(shù)據(jù)。解決辦法是使用dma_wmb()、smp_store_release這類帶屏障語義的接口而不是簡(jiǎn)單賦值。我在FPGA驅(qū)動(dòng)中遇到過一例驅(qū)動(dòng)為DMA準(zhǔn)備好描述符后寫一個(gè)門鈴寄存器通知硬件硬件讀取描述符時(shí)偶發(fā)讀到舊數(shù)據(jù)就是缺少dma_wmb()屏障的典型癥狀。這類問題的排查難度很高我的經(jīng)驗(yàn)是先懷疑內(nèi)存屏障再懷疑鎖使用最后才懷疑硬件。在內(nèi)核工程師圈子里“并發(fā)bug”總是比“硬件bug”概率大得多。5.4 必備調(diào)試工具與內(nèi)核配置內(nèi)核提供了豐富的調(diào)試手段我每次寫驅(qū)動(dòng)前都會(huì)確保內(nèi)核配置打開以下開關(guān)配置項(xiàng)作用CONFIG_DEBUG_LOCK_ALLOC開啟lockdep運(yùn)行時(shí)檢測(cè)鎖順序、死鎖、重復(fù)釋放CONFIG_PROVE_LOCKINGlockdep的完整版鎖使用任何可疑行為都會(huì)報(bào)錯(cuò)CONFIG_DEBUG_ATOMIC_SLEEP檢測(cè)原子上下文睡眠配合might_sleep工作CONFIG_DEBUG_SPINLOCK檢查自旋鎖的非法使用重復(fù)解鎖、未初始化等CONFIG_KASAN檢測(cè)內(nèi)存越界、釋放后使用RCU相關(guān)問題神器運(yùn)行中排查最常用的是/proc/lock_stat它能統(tǒng)計(jì)每個(gè)鎖的競(jìng)爭(zhēng)次數(shù)、等待時(shí)間幫你定位到底是哪把鎖成了系統(tǒng)瓶頸。對(duì)于RCU問題內(nèi)核還有rcu的調(diào)試文件系統(tǒng)節(jié)點(diǎn)可以查看寬限期是否過長、是否有讀者阻塞了垃圾回收。6. 內(nèi)核面試中最高頻的同步問題以及我給的參考答案網(wǎng)上流傳很多Linux面試題清單但同步管理相關(guān)的題目基本固定我把面試官最愛問的幾個(gè)整理出來結(jié)合源碼細(xì)節(jié)給出答題思路。問題1“自旋鎖和互斥鎖的區(qū)別是什么”最核心的區(qū)別是等待機(jī)制自旋鎖忙等待不睡眠適合短臨界區(qū)且能用于中斷上下文互斥鎖睡眠等待讓出CPU適合長臨界區(qū)和進(jìn)程上下文。面試時(shí)能補(bǔ)一句“自旋鎖在單核搶占內(nèi)核中其實(shí)就是關(guān)搶占”并在中斷上下文使用時(shí)需要選spin_lock_irqsave就能和大多數(shù)人拉開差距。問題2“什么時(shí)候用RCU而不是讀寫鎖”回答要點(diǎn)是讀者側(cè)完全沒有鎖開銷適合讀多寫極少且讀者不能睡眠的場(chǎng)景寫者需要復(fù)制修改然后替換指針通過寬限期延遲釋放舊數(shù)據(jù)?？膳e例路由表、文件系統(tǒng)緩存的高頻讀路徑。如果面試官追問“RCU的寬限期是什么”能用“所有讀者離開舊數(shù)據(jù)的時(shí)間段”作答并有call_rcu的調(diào)用經(jīng)驗(yàn)就很有優(yōu)勢(shì)。問題3“一個(gè)驅(qū)動(dòng)中有兩個(gè)鎖如何避免死鎖”標(biāo)準(zhǔn)答案是鎖順序全局一致并用lockdep驗(yàn)證?？梢匝a(bǔ)充盡量減少持鎖的代碼路徑用trylock配合超時(shí)退避以及在調(diào)試內(nèi)核中打開CONFIG_PROVE_LOCKING。問題4“為什么spin_lock_irqsave比spin_lock更安全”spin_lock_irqsave會(huì)保存本CPU中斷狀態(tài)并屏蔽中斷避免當(dāng)前執(zhí)行流被中斷打斷后中斷處理函數(shù)再去搶同一把鎖導(dǎo)致自死鎖。在進(jìn)程上下文和中斷上下文共享同一把鎖時(shí)必須使用irqsave版本。問題5“原子操作和自旋鎖能不能互相替代”不能。原子操作只保證單個(gè)操作不可分割適用于簡(jiǎn)單的加減、交換自旋鎖可以保護(hù)多步驟組成的臨界區(qū)。能用原子操作覆蓋的場(chǎng)景優(yōu)先用原子操作但原子操作本身不具備“鎖住代碼段”的能力。最后再說幾句掏心窩的話我做過多年的驅(qū)動(dòng)開發(fā)和內(nèi)核調(diào)試一個(gè)真實(shí)的體會(huì)是同步管理是內(nèi)核開發(fā)中“最不容易出活但出了事最要命”的部分。它不像實(shí)現(xiàn)某個(gè)功能那樣有看得見的產(chǎn)出但只要并發(fā)模型理解不到位系統(tǒng)就會(huì)在最關(guān)鍵的時(shí)刻給你顏色看。與其等線上事故教做人不如在一開始就養(yǎng)成幾個(gè)習(xí)慣寫臨界區(qū)前先問自己“我現(xiàn)在在哪個(gè)上下文”加鎖時(shí)統(tǒng)一思考鎖順序每次加鎖操作都順手寫注釋標(biāo)明保護(hù)對(duì)象開發(fā)環(huán)境打開lockdep和atomic sleep檢測(cè)有可疑并發(fā)行為時(shí)寧可多用一點(diǎn)同步。我踩坑最多的年頭幾乎都是靠這些樸素規(guī)矩?fù)苹貋淼?。這篇文章從并發(fā)模型講到原語選型從驅(qū)動(dòng)實(shí)操講到事故排查算是把Linux內(nèi)核同步管理的主線梳理完了。內(nèi)核源碼是最好老師kernel/locking/目錄下的注釋和文檔以及tools/locking/里的分析腳本都值得反復(fù)讀。同步管理這東西紙上談兵永遠(yuǎn)不夠拉一個(gè)SMP虛擬機(jī)或者手頭兩塊板子把鎖加進(jìn)去、去掉、壓一下感受一下就全懂了。最后再分享一個(gè)小技巧如果你不確定自己的鎖用法是否正確就在內(nèi)核命令行加lockdep1跑一遍測(cè)試負(fù)載它幾乎能捕捉到每一種潛在死鎖。我無數(shù)次靠這個(gè)開關(guān)提前發(fā)現(xiàn)問題說它是內(nèi)核開發(fā)者的保命符一點(diǎn)也不夸張。