写内核驱动和模块的时候有一类 bug 特别恶心白天正常跑晚上一压测就挂控制台刷出一句 “BUG: sleeping function called from invalid context”顺着调用栈找半天最后发现根子就在某一行代码傻乎乎地以为“现在能睡”。判断当前到底跑在什么上下文里是 Linux 内核开发绕不开的基本功。而聊到上下文判断就绕不开 preempt_count() 和 in_interrupt() 这一对入口一个用来读计数器一个用来查中断位几乎每个驱动维护者在排查诡异崩溃时都见过它们。这篇文章从实际调试视角把这些函数、宏掰开揉碎讲一遍配合我在驱动开发和内核调试里踩过的坑适合写驱动、改内核、排查莫名死锁和crash的读者。1. 上下文判断为什么是内核开发者的必修课1.1 三种常见上下文到底有什么不同内核代码执行时的“上下文”不是玄学而是一组硬约束。最常说的有三种进程上下文、硬中断上下文、软中断上下文。进程上下文就是当前正在执行某个进程的系统调用、缺页异常、内核线程等路径这时候 current 指向的进程有完整的过程状态可以睡眠、可以调度。硬中断上下文是指 CPU 正在跑中断处理函数此时 current 指向被中断打断的那个进程但这个进程可能处于任意状态你不能随便把 CPU 让出去否则中断栈一覆盖、锁一嵌套就乱套。软中断介于两者之间它在硬中断返回后的软中断时机执行也可能由 ksoftirqd 内核线程执行部分场景不允许睡眠。这三种上下文里“能不能睡眠”是最核心的差异。进程上下文里你可以调用 schedule() 睡上一觉等条件满足再回来硬中断上下文里你一旦睡眠中断就永远无法返回谁还会来唤醒你而软中断上下文虽然不在硬件中断栈上但它在很多路径上也是原子性地“借用”当前进程的栈运行睡眠同样会破坏调度器的基本假设。1.2 原子上下文从自旋锁到 preempt_disable除了硬件和软中断还有一个更宽泛的概念叫原子上下文绝不能睡眠的代码路径。它不仅仅是中断处理函数还包括持有自旋锁的临界区。执行 preempt_disable() 之后的临界区。RCU 读锁临界区。某些禁止本地中断或底半部的临界区。处于 NMI 或机器检查异常上下文。这些都是“原子”地占用 CPU 的状态一旦在这个状态里睡眠要么死锁要么破坏调度器。自旋锁的设计初衷就是“等一会儿就拿到锁”如果持有者在临界区里睡大觉其他 CPU 上的竞争者就会一直空转等一个永远不会释放的锁整个系统陷入假死。判断上下文本质上是判断“我现在能不能碰调度器、能不能碰带有睡眠语义的锁”。我自己的经验是看一个函数能不能安全睡眠别靠猜先看它在当前路径上有没有持有 spinlock、有没有关闭抢占、有没有在中断回调里。这几个条件里只要有一个成立睡眠就是炸弹。preempt_count() 和 in_interrupt() 正是帮你快速把条件量化的工具。1.3 判断错误引发的经典故障现场这种错误有一个非常著名的现场中断处理函数或持锁路径里调用了 mutex_lock()或者 kmalloc(..., GFP_KERNEL)。GFP_KERNEL 分配内存时可能触发直接回收、可能睡眠等待于是内核调用 schedule()。调度器发现当前 preempt_count 非零就知道自己在原子上下文立即弹出一段警告BUG: sleeping function called from invalid context at mm/filemap.c:... in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 123, name: kworker/u16:3在早期内核里这条日志基本等于“你完蛋了”因为错误一旦发生内存状态和锁状态已经不可控运气好只是报警运气差直接死锁或者内核 panic。还有一类更隐蔽你以为自己在进程上下文其实是在 tasklet 里你以为 tasklet 可以睡眠不可以tasklet 运行在软中断上下文sleep 等于自杀。这些错误最常见的来源就是调用者想“智能地”根据上下文选择不同路径但又没用对判断宏。搞清楚 preempt_count() 的每一位是理解这些报警信息的基础。2. preempt_count()一个计数器如何扛起半边天2.1 preempt_count 的设计思想和内核数据结构preempt_count 这个名字听起来只是一个抢占次数但实际上它是一整个状态压缩包。在现代内核里它通常是一个 per-CPU 或 per-thread 的 unsigned int通过 preempt_count() 函数读出。老版本内核里它存放在 thread_info 中每次访问还要先拿到 current_thread_info()新版本把很多 per-thread 状态移进了 task_struct访问路径变了但核心思想没变。为什么用位段而不是几个独立原子变量因为很多时候需要一次性读出一致状态而且增减操作都是单条原子指令。比如进入中断的时候要同时把硬件中断深度加上去退出时减回来如果拆成多个变量既慢又要考虑锁同步。位段设计天然保证了一致性。preempt_count() 函数在开启 CONFIG_PREEMPTION 的内核里实际实现通常类似static __always_inline int preempt_count(void) { return raw_cpu_read_4(__preempt_count); }注意它读的是“当前 CPU”的计数。在中断上下文里它反映的是当前 CPU 被打断时的那个进程身上的计数加上中断自己增加的深度。所以它不是个稳定的全局计数器而是和 CPU、进程、中断嵌套实时联动。2.2 位域布局从 PREEMPT_MASK 到 HARDIRQ_MASKpreempt_count 的 32 个 bit 被划分成几段分别记录抢占计数、软中断计数、硬中断计数和 NMI 状态。不同内核版本、不同架构下的位段分配并不完全一致例如有些版本里抢占计数占 8 位另一些只占 1 位NMI 计数可能是单独一段也可能并进硬中断段。这里给一个历史版本中常见的示意#define PREEMPT_MASK 0x000000FF /* 抢占计数 */ #define SOFTIRQ_MASK 0x0000FF00 /* 软中断计数 */ #define HARDIRQ_MASK 0x00FF0000 /* 硬中断计数 */ #define NMI_MASK 0x01000000 /* NMI 计数 */ #define PREEMPT_ACTIVE 0x02000000 /* 老版本调度标记 */注意这只是一个便于理解的示意不是让你背。真要看具体布局去你内核版本里的 include/linux/preempt.h 查。但位段的思路是一致的preempt_count 不是单纯计数它把“抢占深度”“软硬中断深度”这些信息叠在同一个变量里靠掩码区分。硬中断和软中断的计数表示的是嵌套深度不是简单的 0 或 1。一个值等于 2说明发生了同类型中断的嵌套。虽然中断处理过程中一般会屏蔽同级中断但 NMI、以及某些架构的快速中断仍然可能嵌套所以深度不能假设为 1。2.3 preempt_disable/preempt_enable 的完整生命周期抢占调度是 preempt_count 最核心的使用场景。preempt_disable() 就是对抢占计数那一段做加一preempt_enable() 减一减到零时如果 TIF_NEED_RESCHED 被置位就会主动调用调度器。用伪代码表示static __always_inline void preempt_disable(void) { preempt_count_inc(); barrier(); } static __always_inline void preempt_enable(void) { barrier(); preempt_count_dec(); }这里 barrier() 是编译器屏障防止编译器乱序保证临界区内的指令不会被优化到临界区外。很多人只盯着计数加一忽略了 barrier其实它和计数同样关键。如果没有 barrier编译器完全可以把临界区后面的代码挪到 preempt_disable() 之前执行临界区保护就失效了。什么时候抢占计数会大于 1最常见的是嵌套持有自旋锁。自旋锁的临界区本质上是禁止抢占的如果代码里一层接一层持有多个自旋锁preempt_count 的抢占部分就会累加。所以当你看到 preempt_count() 的低八位是 2、3 甚至更大不要觉得奇怪那只是嵌套深度。2.4 善用 preempt_count() 做运行时诊断代码里直接调用 preempt_count() 通常是为了调试或者为了判断当前是否处于某个不可抢占地带。比如你想要一个“当前是否允许抢占”的判断可以写if (preempt_count() PREEMPT_MASK) pr_info(preempt disabled\n);但这只是第一步。更关键的是preempt_count() 的值会和进程切换、中断嵌套实时联动所以它不是个稳定的布尔量而是一个瞬时深度。调试的时候我建议直接在崩溃现场把整个 preempt_count 打印出来而不是只看某个位pr_err(preempt_count%08x hardirq%d softirq%d preempt%d\n, preempt_count(), (preempt_count() HARDIRQ_MASK) HARDIRQ_SHIFT, (preempt_count() SOFTIRQ_MASK) SOFTIRQ_SHIFT, (preempt_count() PREEMPT_MASK) PREEMPT_SHIFT);打印出来的十六进制值可以快速看出是哪一段非零。比如值里只有 HARDIRQ_MASK 那一段是 1说明正在硬中断上下文如果 SOFTIRQ_MASK 和 HARDIRQ_MASK 同时非零说明软中断执行到一半被硬中断打断了。这种现场信息比看代码猜要准确得多。3. in_interrupt() 与它的亲戚们宏背后的位运算3.1 in_interrupt() 怎么算出来的有了位段所有上下文判断宏本质上就是掩码运算。in_interrupt() 的含义是“当前是否处于任何中断相关上下文”它看的是三个位段里是否有非零值通常展开为#define in_interrupt() (irq_count()) #define irq_count() \ (preempt_count() (HARDIRQ_MASK | SOFTIRQ_MASK | NMI_MASK))注意这里的 SOFTIRQ_MASK 不仅仅是软中断执行现场还包括 local_bh_disable() 这类底半部禁用操作也就是你在进程上下文里调用 local_bh_disable() 后in_interrupt() 也会返回真。这是很多人踩过的坑后面我会专门说。in_interrupt() 是“中断相关上下文”的宽泛判断它不区分当前是在硬中断里、软中断里还是 NMI 里。如果你只是想判断“能不能睡眠”in_interrupt() 是不够的因为进程上下文持有自旋锁时它也返回 0但你仍然不能睡。3.2 in_irq()、in_softirq()、in_nmi() 的分工需要更精细判断时内核提供了具体的亲戚宏#define in_irq() (preempt_count() HARDIRQ_MASK) #define in_softirq() (preempt_count() SOFTIRQ_MASK) #define in_nmi() (preempt_count() NMI_MASK)in_irq() 只关心硬中断位段只要硬中断深度非 0 就是真。in_softirq() 只关心软中断位段。这两个宏不互斥因为可能出现硬中断打断软中断执行的情况此时 HARDIRQ_MASK 非 0SOFTIRQ_MASK 也非 0in_interrupt() 仍然为真。in_nmi() 检查 NMI 计数。NMI 栈上的路径比普通硬中断更苛刻任何锁、任何中断操作都可能出问题所以 NMI 处理函数里只允许非常有限的调用。如果代码逻辑里需要区分 NMI 和普通硬中断务必用 in_nmi() 而不是自己猜 NMI_MASK 的位置。3.3 in_atomic() 的边界与争议很多初学者把 in_interrupt() 当作“能不能睡眠”的判断这是个大误区。内核里另一个宏 in_atomic() 是用来覆盖“原子上下文”的。它的定义在不同版本里变过好几次核心思想是检查 preempt_count 里除普通抢占计数之外的位是否有非零但历史上它和 PREEMPT_ACTIVE 位也纠缠过一阵。问题在于不同内核版本里“抢占计数算不算原子”的处理并不一致而且 in_atomic() 在某些配置下可能给出错误的安全感。我自己的习惯是不用 in_atomic() 做最终的睡眠判断而是把“当前能不能睡”交给 might_sleep() 去运行期检测。might_sleep() 会在 CONFIG_DEBUG_ATOMIC_SLEEP 开启时帮你检查当前上下文是否允许睡眠如果不允许直接吐警告。这种方式比你在每个函数里手工判断 in_atomic() 要可靠得多。3.4 新版内核的替代接口in_task/in_hardirq/in_serving_softirq如果你维护过多个内核版本的驱动一定体会过这种痛苦去年好好的代码换个 5.x 内核编译不过原因就是上下文宏被重构过。新版本把宏拆得更细逐渐引入了 in_task()、in_hardirq()、in_serving_softirq() 等更精准的判断。新版中硬中断判断建议使用 in_hardirq()软中断执行现场判断建议使用 in_serving_softirq()后者专门用来判断“正在执行软中断回调”不会受 local_bh_disable() 干扰。in_task() 则用来表示“当前处于普通进程上下文”语义比 in_interrupt() 的取反更清晰。这些接口每个版本行为略有不同写代码前先翻你的内核源码。如果一段代码里频繁使用宽泛的 in_interrupt()而且你又关心到底是硬中断还是软中断请换成更具体的宏。老接口未必不能用但新接口的表达力更强也更容易 review。4. 实操驱动开发里如何正确判断上下文4.1 典型场景中断处理函数与 workqueue 共享代码最经典的实操场景就是内存分配。假设你在写一个网络驱动收包中断处理函数里要把包数据复制一份另有一个 workqueue 线程做周期统计也需要分配缓冲区。两个场景都调用同一个辅助函数static struct buffer *alloc_buffer(size_t size, gfp_t gfp) { return kmalloc(size, gfp); }中断处理里调用struct buffer *buf alloc_buffer(len, GFP_ATOMIC);workqueue 进程上下文里调用struct buffer *buf alloc_buffer(len, GFP_KERNEL);这样设计比“在函数内部判断 in_interrupt() 再选 GFP 标志”要干净得多。因为调用者最清楚自己的路径能不能睡眠被调函数只需要按照参数执行。内核中判断一个 gfp 标志是否允许阻塞有现成接口 gfpflags_allow_blocking(gfp_flags)如果返回 false说明这个分配不允许睡眠。你可以在辅助函数里加个调试断言if (WARN_ON_ONCE(!gfpflags_allow_blocking(gfp) size threshold)) pr_info(possible atomic sleep in %ps\n, __builtin_return_address(0));这类方式比到处 if (in_interrupt()) 可靠得多。4.2 公共函数的上下文参数该传还是该猜公共函数最忌讳自己猜上下文。我见过有些驱动在通用的锁函数里写if (in_interrupt()) spin_lock_irqsave(lock, flags); else mutex_lock(lock);第一眼看很“智能”实际是埋雷。因为进程上下文里也可能已经持有了其他自旋锁此时你选择 mutex_lock 照样睡软中断上下文里也可能 local_bh_disable 被调用过in_interrupt() 返回真但你想要的锁语义可能根本不是按中断与否划分的。正确的设计是由调用者把锁类型选好或者把“是否原子”作为一个参数传进来。内核社区很多 API 就是这么干的比如 spin_lock_irqsave/restore 和 mutex_lock 从来不会合在一个调用里自动切换。如果你实在要写一个既能原子调用又能阻塞调用的函数建议拆成两个函数foo()和foo_atomic()。这虽然增加了接口数量但语义清晰review 的人一眼就能看出哪个路径能睡。4.3 调试上下文问题的三板斧第一板斧开启内核调试选项。在开发内核或驱动时打开 CONFIG_DEBUG_ATOMIC_SLEEP、CONFIG_PROVE_LOCKING、CONFIG_DEBUG_PREEMPT。Lockdep 和原子睡眠检测会在你真正睡错地方时发出详细警告包括调用栈和当前锁的持有者。第二板斧定位到现场后打印 preempt_count()。绝大多数 “sleeping function called from invalid context” 信息的栈顶已经告诉你是哪一行调用了睡眠函数但为什么不能睡需要看 preempt_count 和 lockdep 的持有锁报告。例如in_atomic(): 1, irqs_disabled(): 1说明当前要么中断上下文要么持锁且中断被禁用。结合调用栈判断是哪种。第三板斧用 dump_stack() 或 WARN_ON() 在可疑路径上留标记。把临界区入口和出口都打印 preempt_count看计数是否按预期变化。如果 preempt_count 在某个临界区出口后没有回到原来的值那说明配对错误比如 preempt_disable() 少了个 preempt_enable()或者锁路径在异常分支里提前返回了。4.4 排查中 preempt_count 怎么拆开看有一次我们排查一个网卡驱动的死锁现场抓到的调用栈指向一个统计函数。但诡异的是这个统计函数明明是在 workqueue 里被调用的理论上能睡。打印 preempt_count 后发现低八位的抢占计数是 2而且 HARDIRQ_MASK 为 0。原来是在 workqueue 执行前代码先拿了自旋锁保护一个链表统计函数里又试图调用 mutex_lock于是死锁。这种情况只看 in_interrupt() 是没用的因为 in_interrupt() 返回 0。你必须把 preempt_count 完整拆开才能看到“抢占计数深、但不在中断里”这个真相。排查的时候我习惯直接写一个小的解析函数把每个段都打出来就像这样static void dump_pc(const char *tag) { int pc preempt_count(); pr_err(%s: preempt_count%x (preempt%d softirq%d hardirq%d nmi%d)\n, tag, pc, (pc PREEMPT_MASK) PREEMPT_SHIFT, (pc SOFTIRQ_MASK) SOFTIRQ_SHIFT, (pc HARDIRQ_MASK) HARDIRQ_SHIFT, (pc NMI_MASK) NMI_SHIFT); }在进入临界区前和退出后各调用一次 dump_pc大多数配对问题都能暴露出来。4.5 一个混合驱动场景的代码剖面再举一个完整的混合场景。假设你在写一个 GPIO 驱动中断处理函数收到边沿触发后把事件放进一个 atomic 链表同时唤醒一个 workqueue 去读芯片寄存器。中断里不能直接读寄存器因为读寄存器可能涉及 I2C 总线而 I2C 控制器在总线忙时要睡眠。于是static irqreturn_t gpio_irq_handler(int irq, void *data) { /* 原子操作只能入队不能睡眠 */ list_add_tail(event-node, pending_list); workqueue_work(data-wq); return IRQ_HANDLED; } static void gpio_work_fn(struct work_struct *work) { /* 进程上下文可以睡眠 */ i2c_smbus_read_word_data(client, REG); }这个场景里上下文判断发生在代码组织层面中断函数只做原子动作workqueue 做阻塞动作。如果你非要在中断函数里用 in_interrupt() 去决定“我能不能读 I2C”那就是在错误路口刹车设计上就已经输了。正确的上下文判断应该尽早把函数拆分到正确的上下文里去。4.6 一个自查清单写驱动时我经常在 review 代码时对照这份清单中断处理函数不能睡眠分配用 GFP_ATOMIC锁用 spin_lock/irqsave。tasklet/softirq 回调不能睡眠同一个软中断上下文可能并发执行。workqueue默认进程上下文可以睡但别在持有 spinlock 时睡。timer 回调属于软中断上下文不能睡眠。系统调用路径进程上下文一般可以睡但注意是否持有锁。NMI 处理所有事情都尽量少做x86 NMI 里甚至不能随便用普通 printk。5. 常见问题速查表与避坑心得5.1 常见问题速查表问题原因解决方案in_interrupt() 返回 1但我在普通进程上下文持有自旋锁持有 spin_lock 会把抢占计数加一但这和中断计数无关in_interrupt() 只查中断位段用 in_atomic() 或依赖内核安全检测不要在锁内睡眠in_interrupt() 返回 1但我只是调用了 local_bh_disable()local_bh_disable() 会增加 softirq count使得 in_interrupt() 为真需要判断软中断执行现场时使用 in_serving_softirq()in_irq() 和 in_softirq() 同时为真软中断被硬中断打断hardirq count 和 softirq count 都非零区分场景硬中断优先级更高通常先处理硬中断preempt_count() 值是一大串十六进制数字看不懂它把抢占深度、软硬中断深度压缩在同一个变量里按位段拆开打印看各个计数部分分别为多少换内核版本后代码里的 preempt_count() 行为变了不同版本重定义了位段和宏查看新版本 include/linux/preempt.h改用新版推荐接口单次 preempt_disable() 后计数变 2可能中间又进了一次中断/持锁或者配对错误在入口/出口打印计数追踪检查所有提前 return 路径5.2 我踩过的 local_bh_disable 之坑这是我在真实项目里踩过最深的坑。local_bh_disable()会把 softirq count 加一如果你在它保护的临界区里去读 in_interrupt()会发现结果为真。但这里其实是在进程上下文只是底半部被临时关掉。把 in_interrupt() 当成“是否在中断回调”就会误判。那次问题出在一个网络协议栈的统计代码里。代码意图是如果当前在中断上下文就用一个精简统计路径否则走完整统计。结果因为某个通知链在调用统计函数前先 local_bh_disable()in_interrupt() 一直为真所有请求都走了精简路径丢了一堆统计信息。查了两天才发现罪魁祸首就是 in_interrupt() 的语义比想象中宽。内核社区因此推荐用 in_serving_softirq() 判断“正在执行软中断处理”它不会被 local_bh_disable() 干扰。如果你发现自己的代码里频繁使用宽泛的 in_interrupt()而且又关心到底是硬中断还是软中断请换成更具体的宏。5.3 最终建议还有一个“土办法”我用了很多年在可疑路径入口把 preempt_count() 存到局部变量出口时再读一次比一比如果不一致就顺着提前返回点找漏掉的 preempt_enable()。这个办法在没有 lockdep 的嵌入式内核里尤其好用。最后再分享一个小技巧不要光在 bug 出现后看 preempt_count()平时也可以在 kmalloc、mutex_lock 这些公共路径上挂上 tracepoint用 ftrace 观察抢占和中断的开关情况。能把 preempt_count 的变化曲线拉出来再难排查的上下文错乱问题也会有线索。判断上下文这件事最终靠的不是记住每个宏的返回值而是把 preempt_count 的每一位当成心跳读数读懂整个系统的实时状态。