说到竞态条件追踪与内核锁这是我在处理内核模块崩溃时最常面对的战场。前段时间刚帮同事排查一个驱动死锁现象是运行两天才崩一次dmesg里只有一段莫名其妙的内核告警重启后就消失抓了好几轮都没头绪。后来把系统切到带完整检测工具的调试内核才锁定了两个并发路径在抢同一个共享变量。这种事在内核开发里太常见了一个不加保护的整型计数器一次丢失的中断屏蔽都可能让原本稳定的系统变成定时炸弹。这篇指南就是想把竞态条件追踪与内核锁相关的实战经验整理出来聊聊竞态为什么会发生、锁家族怎么选、以及用哪些工具能把看不见的并发问题抓出来。适合正在写Linux驱动、搞内核模块开发或嵌入式Linux调优的朋友参考也适合运维同学在面对“偶发panic”时建立排查思路。1. 竞态条件为什么是内核开发的“头号刺客”1.1 一个数据错乱引发的“血案”实例先分享一个我实际遇到过的场景。某款网卡驱动维护一个统计结构其中有一个字段记录丢包次数发送路径在软中断里做累加用户态则通过ioctl去读取这个值顺便清零重置。代码大概长这样struct rx_stats { u32 dropped; u32 total; }; /* 软中断收包路径 */ void eth_rx_poll(struct rx_stats *stats) { stats-dropped; /* 没有保护 */ } /* 用户态控制路径 */ static int eth_ioctl(struct net_device *dev, unsigned int cmd, unsigned long arg) { struct rx_stats stats; memcpy(stats, dev-priv, sizeof(stats)); stats.dropped 0; /* 想要清零 */ memcpy(dev-priv, stats, sizeof(stats)); return 0; }一开始测试没怎么跑流量一切正常。等压测到10G线速时偶尔出现total值比dropped还小的情况用户态拿到的丢包率甚至变成负数。单看程序逻辑没人会写错但并发执行时dropped这条看似简单的指令在CPU层面其实是“读旧值-加一-写回”三步。如果软中断和ioctl同时对这个字段操作完全可能发生软中断加了3包ioctl又用旧值覆盖回去计数直接倒退回清零状态。这种问题没有锁靠“试几次没复现”根本防不住。这个案例其实非常典型。很多人觉得数据错乱一定伴随崩溃或告警实际上竞态最阴险的地方在于它会悄悄破坏数据一致性而且触发概率可能很低低到你怀疑人生。一旦出现“偶发、不可稳定复现、换CPU也能出现”的怪异问题首先要怀疑的就是并发共享数据。1.2 竞态的三个必要条件与并发来源按我对竞态的理解要形成竞态条件需要三个条件同时成立有至少两个执行流访问同一份共享资源其中至少一个执行流在修改这个资源访问时没有保证原子性。三个条件缺一个都不会产生问题因此排查思路也就顺着这三个条件展开找共享变量、找并发路径、找缺失的同步机制。内核里的并发来源比普通用户态程序丰富得多这也是内核开发调试困难的原因。典型来源包括多核SMP上多个CPU同时执行代码、硬件中断随时打断当前进程、软中断和tasklet运行在中断上下文、内核抢占导致进程被切换以及进程在等待事件时主动休眠唤醒。换句话说即使你写的是一个单核系统中断和异常也会让代码路径“重叠”。用生活化一点的类比房间里有一个账本两个人同时都要记账。第一个人翻到本子第10页记了一笔还没放下笔第二个人也翻到第10页接着写两个人很可能都把金额写在同一个位置覆盖掉对方。为了不出现这种情况要么让其中一个排队要么把账本加上一把锁要么把记账动作设计成一次写完。内核里的封锁、原子操作、RCU本质上都是这三类思路的具体实现。1.3 原子性、临界区与锁的基本逻辑所谓原子性就是一段操作在执行过程中不能被其他执行流插入或打断从外部看它要么完整执行完要么像完全没执行过一样。“临界区”则是代码中被锁包裹起来的那一段锁的作用就是让同一时刻只有一个执行流能进入临界区。要注意一个很容易误解的点锁本身并不保护数据锁保护的是“对数据的操作序列”。也就是说哪怕你在一个路径上加了锁另一个路径没有加锁数据依然可能被并发破坏。就像大家都约定进会议室要刷卡但有人就是不刷卡推门进去门禁形同虚设。修复竞态的第一步往往不是“选哪种锁”而是先把所有会访问这个共享资源的路径都盘点清楚。另外内核同步不是越快越好。锁越细并发性能越好但代码复杂度越高锁越粗越不容易写错但CPU可能被白白卡住。后面讲锁家族时我会反复提到这个权衡。2. 内核锁家族全景选型比会写更重要2.1 自旋锁适合“短小精悍”的临界区自旋锁是内核里最基础和最常见的锁。它最大的特点是忙等待当一个CPU想获取已经被别人持有的自旋锁时它会在原地打转反复检查锁状态直到持有者释放。因为自旋锁不会让出CPU所以它可以在中断上下文和禁止抢占的代码路径里使用。使用自旋锁时最容易犯的错误是临界区太长。假设临界区里做一次耗时的寄存器操作或者调用了mdelay那其他想进临界区的CPU就全部空转白白消耗处理器时间。更严重的是如果临界区里调用了可能睡眠的函数比如msleep、mutex_lock、kmalloc(GFP_KERNEL)在进程上下文还好说一旦在中断上下文触发系统直接进入不可预测状态最常见的结果是“BUG: scheduling while atomic”或者软死锁。适合用自旋锁的场景有对寄存器的读写、对简单标志位的修改、对共享链表进行短操作。操作系统的直觉是临界区执行时间在几十微秒以内且不允许睡眠时优先考虑自旋锁。需要特别说明的是spin_lock_irqsave和spin_lock_irqrestore。当你有一个数据既会被进程上下文访问又会被中断处理函数访问时绝不能只使用普通spin_lock。因为普通spin_lock只关闭内核抢占不会屏蔽中断。进程在临界区里持锁时被中断打断中断服务函数又去获取同一把锁就会陷入“自己等自己”的死锁。spin_lock_irqsave会在持锁的同时保存当前中断标志并屏蔽中断释放时再恢复这样才能彻底把并发路径隔开。2.2 互斥锁与信号量允许睡眠的场景别硬扛互斥锁和自旋锁最大的区别在于互斥锁在获取不到时会睡眠让出CPU因此只能在进程上下文使用。它的好处是临界区可以很长甚至可以在临界区里执行阻塞式I/O。mutex_lock和mutex_unlock是内核最常用的mutex接口。我见过不少新手在中断处理函数里直接用mutex理由是“这个锁更好用”结果系统panic。原因很简单中断上下文不允许睡眠而mutex在锁被占用时会触发调度。往大了说这就是本文核心概念在“上下文约束”上的具体体现选锁不仅要看临界区多长还要看代码运行在什么上下文里。信号量算是一个更古老的同步机制了它允许计数大于等于1也就是可以有多个持有者。在内核开发里普通互斥场景基本都被mutex取代信号量只在少数特殊场景比如读写资源计数还在用。如果你不是写通用调度或驱动框架看到信号量时可以先问问维护者为什么要用它不要习惯性地拿它替代mutex。对于初学者我的建议很简单进程上下文、临界区可能较长、需要睡眠等待老老实实用mutex不能睡眠的上下文用自旋锁或原子操作。2.3 读写锁、RCU 与原子操作为特定读写模型而生读写锁rwlock_t允许多个读者同时进入临界区但写者必须独占。理论上读写锁能在“读多写少”的场景下提高并发度但实际内核里使用读写锁要格外小心。因为读写锁在读锁内部如果用普通自旋锁实现写者等待时不会去通知读者让位极端情况下写者会被读者“饿死”。所以rwlock_t适合读多写少且临界区很短的情况。RCU是另一种很巧妙的同步机制它的核心思想是“读侧几乎无锁”。读端只需要通过rcu_read_lock标记一个读侧临界区内部通常只做抢占关闭成本极低写端则先修改数据等待所有在读侧临界区里的读者都退出后再释放旧数据。这个等待过程叫宽限期。RCU非常适合链表遍历、路由表查找这类读多写少的场景但实现复杂度较高新手不建议一上来就自己造RCU数据结构先学会在现有RCU保护的保护下操作。原子操作则是另一种思路我不加锁直接把“读-改-写”合并成一个不可分割的CPU指令。内核提供atomic_t、atomic_long_t以及对应的atomic_inc、atomic_dec_return等接口。回到最初那个统计计数的例子只要把dropped改成atomic_t然后所有路径都使用atomic_inc问题就消失了。原子操作的好处是轻量、不会睡眠、不会死锁缺点是无法保护复杂的多步操作。另外一个容易被忽略的是顺序锁seqcount_t。它允许读者在读的同时写者也能写读者在读完后校验一个序号如果发现序号变化就重试。它适合写者频繁且读者可以容错的场景比如实时时钟读取。2.4 锁选择速查表和“性能-安全”权衡为了让选型更直观我把常用同步机制整理成了一张速查表同步机制是否允许睡眠适合场景注意事项自旋锁否短临界区、中断上下文临界区内禁止睡眠需要时配合中断屏蔽互斥锁是长临界区、进程上下文不可在中断上下文使用信号量是资源计数、多读者普通互斥已被mutex取代读写锁否读多写少、写者较少防止写者饿死RCU读侧不睡眠读频繁、写极少实现复杂需理解宽限期原子操作是单一计数器、标志位只保护单个变量顺序锁是写者优先的读写场景读者可能重试选锁时我一直坚持一条原则先从共享数据的访问频率和上下文下手再决定同步机制而不是反过来先“挑一把好看的锁”。如果你不确定宁可先用互斥锁把进程上下文逻辑跑通再用性能分析工具去优化。先保证正确再谈效率。3. 实战追踪把看不见的竞态“抓出来”3.1 第一道防线开启内核配置中的追踪开关很多竞态问题之所以“失踪”是因为默认内核没有开启足够的调试信息。开发阶段一定要编一个带调试选项的内核这是性价比最高的一步。我建议至少开启下面这些配置CONFIG_DEBUG_KERNELCONFIG_PROVE_LOCKINGlockdep锁依赖验证CONFIG_DEBUG_SPINLOCKCONFIG_DEBUG_ATOMIC_SLEEPCONFIG_KCSAN内核数据竞争检测器CONFIG_DEBUG_OBJECTS这些选项在性能上有一定开销生产环境不建议常开但开发机和压测机务必开启。特别是CONFIG_PROVE_LOCKING它会在运行时记录每次获取锁的依赖关系然后自动检查是否有循环依赖一旦发现死锁隐患会立刻输出大段报告。这个报告对于排查锁顺序问题几乎是“开卷考试”。开启这些配置后我通常会做一个基线测试同样的压力脚本先跑半小时确认没有其他无关告警再开始加新驱动或新代码。这样后续KCSAN或lockdep的报错才可信不会被原有问题干扰。3.2 用 lockdep 自动检测锁顺序错误与死锁lockdep的全称是Lock Dependency Validator它并不直接检测正在发生的死锁而是检测“潜在的死锁可能性”。当内核获取锁时lockdep会记录当前CPU已经持有的锁列表把这个列表当作一个依赖节点锁A之前曾持有锁B就建立了一条B→A的依赖。如果后续出现了A→B的依赖两条边形成环lockdep就会报告“possible circular locking dependency detected”。拿到这类报告别慌先看第一行提示的“possible circular locking dependency detected”然后根据报告中的两个锁名和调用路径找到第一次出现循环依赖的代码位置。比如它可能提示你在某个驱动中先拿了stats_lock再拿dev_lock而在另一个路径上顺序恰好相反这就是AB-BA死锁隐患。修复的方法很简单统一全内核的锁顺序比如约定“永远先dev_lock再stats_lock”然后在涉及其锁的路径里调整获取顺序。lockdep最有价值的不是它直接帮你改代码而是它会逼着你把锁的使用规则想清楚。我调试过一个模块加锁路径分散在五个文件里自己看半天都看不出顺序问题但lockdep一次压测就报了出来。从那以后我写多锁代码之前一定会先画一个“锁顺序表”放在注释里减少这类问题。运行中也可以主动检查当前系统是否有死锁报告常用的命令是dmesg | grep -i possible circular如果已经有报告说明问题可能一直存在只是你没注意。另外还可以在运行时动态验证某个文件或模块的锁图比如lockdep的/proc/lockdep_stats和/proc/lockdep_chains节点能提供锁依赖数量的统计信息。3.3 用 KCSAN 定位数据竞争KCSAN全称Kernel Concurrency Sanitizer是编译时数据竞争检测器。它的工作原理是在访问共享内存地址时插入检查点通过采样判断两个访问是否有同步保护。如果两个执行流访问同一个地址其中一个是写操作且二者之间没有建立锁或其他同步关系KCSAN就会输出一个data-race报告。最好的使用方式是配合压力测试。比如我刚才提到的网卡驱动问题在开启CONFIG_KCSAN后跑一轮流量压测dmesg里就出现了BUG: KCSAN:>trace-cmd record -p function_graph -l eth_rx_poll -l eth_irq_handler trace-cmd report这样能把特定函数的调用图、执行时长、中断上下文都呈现出来帮你判断临界区是否过长或者某个路径是否被中断打断。perf则更适合采样和分析并发热点。配合perf probe你可以在特定函数入口动态打点然后采样调用栈perf probe -a eth_rx_poll stats perf record -e probe:eth_rx_poll -ag -- sleep 10 perf script通过对比两个路径的调用栈往往能快速确认是否存在交叠。这个方法比KCSAN更“手工”但优点是可以针对老内核或已经部署的模块做动态诊断不必重编内核。我曾经在排查一个诡异问题时用过组合拳先用KCSAN确认竞态地址再用ftrace追踪两个路径的执行频次最后用perf probe确认其中一个路径每秒钟执行了数万次而另一个路径虽然频率低但每次访问都正好撞上。这个执行频率差异帮我判断应该用原子操作还是用锁极高频率的读改写原子操作比自旋锁更合适。3.5 从宕机现场反向追踪竞态的流程如果问题已经严重到系统panic而且你没有提前开启KCSAN或lockdep也不要直接放弃。保留好崩溃现场用crash工具链反向追踪往往也能还原真相。前提是内核开启了CONFIG_KASAN和CONFIG_CRASH_DUMP并配置好了kdump。拿到vmcore后我一般按这个顺序排查用crash加载vmlinux和dump文件执行bt查看每个CPU的调用栈。对比各CPU栈看是否有两个栈同时访问同一地址或同一结构体。如果看到两个CPU都在操作同一个“已知对象”比如同一个skb或同一个net_device这就高度可疑。用kmem或struct命令查看目标结构的内容检查引用计数、链表指针、计数器是否处于“半更新”状态。如果怀疑某个字段被静默覆盖可以在崩溃函数附近的变量地址上用wr或rd检查内存内容结合对象分配地址判断谁写了它。这个方法成本较高但有时候是唯一手段。我记忆力里比较深刻的一次就是用crash查出一个驱动在共享结构体里多线程并发操作同一个hrtimer对象导致timer的链表指针错乱。crash的调用栈显示两个CPU都在调用hrtimer_cancel而对应结构体的锁加在了另一个路径上保护没有覆盖到。这类问题靠代码审查很费劲靠现场证据反而更快。4. 修复竞态的典型套路与代码落地4.1 修正一个真实驱动竞态的完整过程下面把一个完整的修复过程拆开讲。还是继续用那个统计丢包数的驱动分五步走。第一步现象与复现。用户反馈在高负载下偶尔读到的丢包率为负数。我在测试机上开启KCSAN并用脚本反复触发ioctl读取加清零同时用iperf打满流量。半小时后dmesg出现data-race报告确认了两个路径。第二步梳理所有访问路径。我把源码里所有访问stats-dropped和stats-total的代码全部列出来发现除了中断累加、ioctl清零外还有一个proc文件读取接口也会读取统计。我需要保证这三条路径互不干扰。第三步选择修复方案。累加和清零操作本质上是对单一整型的读写最简单可靠的是改成atomic_t。如果涉及多个字段组合一致性那就要用锁。这里只动一个字段用原子操作最合适不会引入睡眠问题也不影响中断上下文。修改后struct rx_stats { atomic_t dropped; atomic_t total; }; void eth_rx_poll(struct rx_stats *stats) { atomic_inc(stats-dropped); } static int eth_ioctl(...) { struct rx_stats stats; stats.dropped atomic_read(dev-stats.dropped); stats.total atomic_read(dev-stats.total); atomic_set(dev-stats.dropped, 0); atomic_set(dev-stats.total, 0); return 0; }第四步重新编译并开启KCSAN验证。压力测试继续跑24小时没有data-race报告用户态读到的丢包率也不再出现负数。第五步再跑一遍lockdep确认锁依赖没有变化。虽然这次没用锁但确认一下至少不引入新的同步问题。这个流程的核心在于“先盘路径再选机制”。很多人在第一步就卡住了因为他们只凭“感觉”认为某个变量有问题却不知道还有多少路径在碰它。我的习惯是给每个共享变量建一个函数访问清单所有函数名列出来谁加了锁、谁没加锁一眼可见。4.2 锁注释与依赖建模让 lockdep 真正有用lockdep对锁依赖图自动建模但前提是你把锁对象的生命周期和获取顺序设计明确。我在实际项目中见过一些代码明明是同一把锁却因为两次获取之间事务太复杂导致lockdep反复误报。这不是lockdep的错而是代码没有按锁依赖的规则组织。比较实用的做法是在包含锁的结构体注释里写明锁的使用规则比如/** * stats_lock: 保护stats结构的访问。 * 获取顺序必须先获得dev_lock再获得stats_lock。 * 中断上下文中使用 spin_lock_irqsave 版本。 */这样lockdep报出来的依赖链维护者可以直接对照注释判断是否是合法依赖。同时这也逼着后续改代码的人遵循既定顺序而不是随手加锁。另外初始化锁对象时最好在模块初始化函数中调用对应锁的*_init接口不要直接零初始化后使用。虽然自旋锁在静态定义时可以用DEFINE_SPINLOCK但动态分配的对象里嵌入锁时一定要先初始化。否则lockdep会报告“lock is uninitialized”或者权限错误。4.3 一些“看起来很对但其实是坑”的写法写并发代码多年我总结了几个典型的“坑型写法”每一个都看过真实案例只在读路径加锁写路径不加锁。最典型的认知误区。一个进程在读共享数据前加了锁但另一个中断处理函数修改数据时完全没碰锁数据照样被撕裂。用volatile替代锁。volatile只能告诉编译器不要优化对该变量的访问不会生成原子指令更不能做临界区保护。两个CPU上的volatile变量的读改写照样会互相覆盖。先判断条件再加锁再检查条件。比如“先判断缓冲区是否为空为空再加锁等待”的顺序是错的判断和加锁之间仍存在竞态窗口。正确姿势是加锁后再判断或者用wait_event一类的条件睡眠接口。在持有自旋锁时调用kmalloc(GFP_KERNEL)。GFP_KERNEL可能睡眠在自旋锁临界区内执行等于违反“不能睡眠”约束。需要分配内存时优先在进临界区之前做好准备。两个进程分别用不同锁保护同一共享数据。虽然看起来每个路径都有锁但保护的不是同一把锁并发依然存在。这些问题的共性是写代码的人只看到了自己所在路径没有完整画出所有并发路径。在并发领域代码的“局部正确”没有任何意义必须在全系统层面保证一致性。5. 常见问题与排查技巧实录5.1 问题速查表实际排查中掌握“症状→原因→工具→解决办法”的映射能省很多时间。我把常见的几类情况整理成了速查表症状可能原因推荐工具解决方向偶发崩溃dmesg无明确头绪数据竞争导致内存错乱KCSAN全路径加锁或改用原子操作系统运行一段时间后soft lockup自旋锁临界区过长或死锁lockdep缩短临界区调整锁顺序中断触发后系统Panic中断上下文使用了睡眠锁CONFIG_DEBUG_ATOMIC_SLEEP改用自旋锁或延迟处理统计计数异常且值“倒退”多个路径在无锁状态累加/清零代码审查统一原子操作或锁保护两个CPU栈同时访问同一结构锁覆盖范围不足crash工具绘制访问路径补锁一次正常函数调用触发了调度在原子上下文里调用了睡眠函数ftrace/perf把耗时代码移到工作队列这套表不是死的但可以帮你建立排查框架。遇到问题先套一遍通常能定位到具体方向再针对性深入。5.2 锁定屏中断与下半部的注意事项内核里除了获取锁本身还经常需要关闭中断或关闭下半部来避免竞态。local_irq_disable和local_irq_enable是用来在本地CPU上关闭中断的但这是非常霸道的做法它会增加中断延迟甚至影响实时性。我在驱动代码里见到过不少为了省事直接调它的这个习惯相当危险。对中断共享的保护更合理的方案是使用spin_lock_irqsave而不是裸调local_irq_disable。因为中断屏蔽状态需要原样保存和恢复防止你在一个已经屏蔽中断的上下文中再次关闭中断最后恢复时却错误地打开中断破坏之前的状态。软中断softirq和下半部也有类似的屏蔽接口local_bh_disable和local_bh_enable。如果中断处理函数访问某数据结构而进程上下文也要访问一种常见做法是同时使用spin_lock_bh它会在获取锁时关闭当前CPU的软中断防止下半部重新调度。它比spin_lock_irqsave更轻量适合只和下半部争用的场景。我给你的核心建议是不要滥用中断屏蔽。能用锁解决就用锁能用原子就原子只有在中断处理路径特别短且和当前进程有强竞争时才考虑配合中断屏蔽。屏蔽中断的时间越短越好千万不能在屏蔽中断里做长时间循环。5.3 经验先复现再定位还是先审查再定位这个问题每次都会被问到。我的答案是能复现就先复现不能复现就先审查。前者效率高后者价值大。能复现的意思是你能用相对可控的脚本或测试流程稳定触发问题。这时直接开KCSAN和lockdep再加上压测通常很快就能拿到精确报告。怕就怕所谓“复现”其实只是“跑了很多次终于出现一次”这种状态下开各种检测器反而会拖慢系统导致更难触发。我通常会把压力等级分成三档从低到高逐步往上加找到“稳定触发”的最小压力阈值然后再开检测器。不能复现时我会立刻转入手工审查。方法是建立“共享数据访问表”把模块里所有全局变量、嵌入结构体的字段、通过指针传递的对象全部列出来标记每种访问发生的上下文进程、硬中断、软中断、tasklet再看哪些条目有至少两个访问上下文且没有同步保护。这张表看起来笨但往往能发现连KCSAN都没抓到的问题因为KCSAN只关心已发生的访问而审查可以分析潜在访问。根据我个人经验竞态问题最忌讳的是“修一下试试看”加锁位置不对可能问题暂时消失但只是概率变小并没有根除。我会反复问自己三个问题访问这个数据的路径有没有全部覆盖覆盖动作之间有没有保持统一顺序有没有可能睡眠的代码被放进了不可睡眠的上下文这三个问题答清楚绝大多数竞态都能防住。最后再分享一个小技巧每次修完竞态问题保留一份“当时的KCSAN古董日志”存进代码注释或者变更记录方便以后快速定位类似问题也方便让后来者看到这个字段曾经踩过的坑。