在嵌入式Linux开发中，你是否遇到过系统运行一段时间后莫名卡死、某个外设间歇性失灵，或者在高负载下出现难以复现的时序错乱？很多时候，我们习惯于从应用层、驱动逻辑甚至硬件本身去排查，却忽略了一个底层但至关重要的因素—— 内核抢占（Preemption） 。尤其是在追求实时性的场景下，启用 PREEMPT_RT 等高抢占性内核配置，就像一把双刃剑，它在提升响应速度的同时，也可能将你代码中潜藏已久的、在非抢占或低抢占环境下“相安无事”的并发缺陷彻底暴露出来。本文将以一个真实的项目调试案例（ER2026）为线索，深入剖析抢占机制如何放大并发隐患，并提供一套从理论到实践的系统性排查与加固方案。

1. 背景与核心概念：抢占、并发与隐藏的缺陷

在深入案例之前，我们有必要厘清几个核心概念，理解它们之间的关联。

1.1 Linux内核的抢占模式

Linux内核并非天生就是完全可抢占的。它的抢占能力是一个可配置的频谱，主要分为以下几种模式：

  • CONFIG_PREEMPT_NONE (无抢占) ： 内核态不可抢占。一个进程在内核态执行时，除非主动放弃CPU（如调用 schedule() 或阻塞），否则会一直运行直到返回用户态。这是传统服务器内核的默认配置，吞吐量最高，但延迟最不可预测。
  • CONFIG_PREEMPT_VOLUNTARY (自愿抢占) ： 在内核代码的关键路径中插入了许多“抢占点”，内核可以在此点自愿让出CPU。这在一定程度上改善了响应性，但仍不是强制的。
  • CONFIG_PREEMPT (可抢占内核) ： 大部分内核代码路径都是可抢占的，除非在持有自旋锁（spinlock）或显式禁止抢占的临界区内。这是桌面和通用嵌入式系统的常见配置，在响应性和吞吐量间取得平衡。
  • CONFIG_PREEMPT_RT (实时抢占) ： 这是 PREEMPT 的“完全体”。它致力于将内核最大程度地可抢占化，甚至将许多自旋锁替换为可睡眠的互斥锁（rt-mutex），并将中断处理线程化（IRQ threads）。其目标是提供确定性的低延迟，是硬实时或软实时应用的首选。

简单比喻 ： NONE 模式像一辆不能超车的火车； VOLUNTARY 模式在固定站点可以上下客； PREEMPT 模式在大部分路段允许超车，但有少数“单行道”（自旋锁）； PREEMPT_RT 模式则试图将所有道路都变成可超车的，并把路障（中断）也管理起来。

1.2 抢占如何加剧并发问题

并发问题，如数据竞争（Data Race）、死锁（Deadlock）、优先级反转（Priority Inversion），其根源在于对共享资源的非同步访问。在低抢占环境下，由于任务切换不那么频繁，两个任务“撞车”访问同一资源的概率相对较低，一些有缺陷的代码可能侥幸运行很久都不出问题。 然而，一旦切换到高抢占模式（如 PREEMPT_RT ）：

  1. 任务切换频率急剧增加 ： 内核抢占点无处不在，高优先级任务可以随时打断低优先级任务。这使得共享资源被交错访问的概率呈指数级增长，原本罕见的竞争条件变得常见。
  2. 锁的语义发生变化 ： 在 PREEMPT_RT 中，大部分自旋锁被替换为可睡眠的互斥锁。如果你的驱动或内核模块错误地假设了自旋锁的上下文（例如，在自旋锁内调用可能睡眠的函数），在 PREEMPT 下可能只是有风险，在 PREEMPT_RT 下则会导致立即死锁或内核错误。
  3. 中断上下文与进程上下文 ： PREEMPT_RT 将中断处理程序线程化，这意味着大部分“中断上下文”变成了“进程上下文”。原来依赖中断上下文不可抢占（即中断处理不会被同一CPU上的其他中断打断，但不同CPU有并发）而省略锁保护的代码，现在面临真正的进程间并发，必然出问题。

结论 ： 高抢占内核不是一个简单的“性能开关”，它是一个压力测试器，会无情地暴露你系统中所有脆弱的同步假设。ER2026项目遇到的问题，正是这一现象的典型体现。

2. 环境准备与版本说明

在开始分析具体案例前，请确保你的实验或排查环境一致。本文的讨论基于以下通用环境，但原理适用于所有Linux内核。

  • 操作系统 ： Ubuntu 20.04 LTS / 或任何主流嵌入式Linux发行版
  • 内核版本 ： Linux Kernel 5.10.y （这是一个长期支持版本，广泛用于嵌入式领域）。关键配置在于抢占模式。
  • 工具链 ：
    • gcc & make : 用于内核编译和模块编译。
    • git : 获取内核源码。
    • stress-ng 或 cyclictest : 系统压力与延迟测试工具。
    • perf 或 ftrace : 性能剖析与跟踪工具，用于定位问题。
    • addr2line 或 gdb / kgdb : 用于将内核Oops信息中的地址解析为代码行。
  • 硬件平台 ： 案例基于一款通用ARMv8开发板（如RK3568），但问题本身与架构无关。
  • 内核配置检查 ： 
    # 查看当前内核的抢占配置
zcat /proc/config.gz | grep -E “PREEMPT|PREEMPTION”
# 或在内核源码目录下，查看 .config 文件
grep -E “CONFIG_PREEMPT|CONFIG_PREEMPTION” .config
    你会看到类似 CONFIG_PREEMPT=y , CONFIG_PREEMPT_RT=y 或 CONFIG_PREEMPT_NONE=y 的输出。

3. ER2026案例详解：抢占暴露的驱动缺陷

项目背景 ： ER2026设备是一款工业IO采集模块，其驱动基于一个较老的版本修改而来。在原内核（ CONFIG_PREEMPT_NONE ）上长期运行稳定。为了满足新的实时控制需求，项目组将内核切换为打了 PREEMPT_RT 补丁的实时内核。随后，系统在连续运行数小时至数天后，会随机出现以下一种或多种现象：

  1. 某个SPI接口的传感器数据突然永久性丢失。
  2. 系统日志中出现内核Oops信息，指向驱动中的某个函数。
  3. 用户态监控进程无响应，但系统其他部分似乎还在运行。

3.1 初步分析与复现

首先，我们排除了硬件问题。然后在 PREEMPT_RT 内核上，使用 stress-ng 对系统施加CPU、内存和IO压力，同时运行 cyclictest 测量实时延迟。 

# 在一个终端运行压力测试
stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 256M --timeout 30m
# 在另一个终端运行延迟测试
cyclictest -t -p 80 -n -i 1000 -l 100000

数小时后，问题成功复现。 dmesg 中出现了关键的错误信息： 

[ 1234.567890] BUG: scheduling while atomic: irq/34-spi1/123
[ 1234.567901] Call Trace:
[ 1234.567910] [<ffffffffc0123456>] er2026_data_read+0xab/0x120 [er2026_driver]
[ 1234.567925] [<ffffffffc0123789>] er2026_irq_handler+0x45/0x78 [er2026_driver]

“scheduling while atomic”是一个经典错误，意味着在原子上下文（不可睡眠的上下文，如中断处理、持有自旋锁时）中尝试进行可能导致睡眠的操作（如申请内存、获取互斥锁）。

3.2 问题根因：错误的锁与上下文假设

我们深入分析驱动代码 er2026_driver.c 。关键函数如下： 

/* 伪代码，展示问题模式 */
static irqreturn_t er2026_irq_handler(int irq, void *dev_id)
{
    struct er2026_device *dev = dev_id;
    unsigned long flags;

    // 问题点1：在中断处理函数中使用了 spin_lock_irqsave
    // 在PREEMPT_RT下，中断处理可能是线程，这个锁会变成可睡眠的rt_mutex？
    // 实际上，对于线程化中断，内核提供了 local_lock 等机制，但这里用法有风险。
    spin_lock_irqsave(&dev->data_lock, flags);

    // 读取硬件状态寄存器
    dev->raw_status = ioread32(dev->mmio_base + STATUS_REG);

    if (dev->raw_status & DATA_READY_MASK) {
        // 问题点2：在锁内调用了可能睡眠的函数！
        // er2026_data_read 内部使用了 kmalloc(GFP_KERNEL) 来分配临时缓冲区。
        // GFP_KERNEL 标志在内存紧张时可能睡眠。
        if (er2026_data_read(dev) < 0) {
            dev_err(dev->device, “Failed to read data\n”);
        }
    }

    spin_unlock_irqrestore(&dev->data_lock, flags);
    return IRQ_HANDLED;
}

static int er2026_data_read(struct er2026_device *dev)
{
    // 这里使用了 GFP_KERNEL，在原子上下文中是禁止的！
    void *temp_buf = kmalloc(BUFFER_SIZE, GFP_KERNEL);
    if (!temp_buf)
        return -ENOMEM;
    // ... 从硬件读取数据到 temp_buf ...
    kfree(temp_buf);
    return 0;
}

根因分析 ：

  1. 锁的误用 ： 在原非抢占内核中，中断处理函数是不可抢占的原子上下文。 spin_lock_irqsave 在这里主要是为了屏蔽本地中断，防止同一中断重入，并保护 dev->raw_status 。由于整个中断上下文不会睡眠，所以即使 er2026_data_read 内部有 GFP_KERNEL 分配，只要内存充足，就不会触发睡眠，问题被隐藏。
  2. PREEMPT_RT 的颠覆 ： 在 PREEMPT_RT 内核中，中断被线程化。 er2026_irq_handler 实际上是在一个内核线程中运行，它处于 进程上下文 ，是可以被抢占和睡眠的！此时， spin_lock_irqsave 可能被替换成一种可睡眠的锁实现。更重要的是，在锁内调用 kmalloc(GFP_KERNEL) 变得合法（从上下文角度看），但这引入了新的死锁风险：如果内存回收需要等待I/O，这个线程会睡眠，而它却持有着锁 dev->data_lock 。其他需要该锁的线程（如另一个中断线程或用户进程）将被阻塞，可能导致系统挂起。而我们的Oops信息正是由于在某种深层调用路径中，内核检测到了不安全的调度点。

3.3 解决方案：重构驱动以适应高抢占环境

修复的原则是： 明确代码执行上下文，严格区分原子上下文和可睡眠上下文，并选择正确的同步原语。

修复后的代码示例 ： 

#include <linux/interrupt.h>
#include <linux/slab.h>
#include <linux/workqueue.h> // 引入工作队列

struct er2026_device {
    // ...
    spinlock_t status_lock; // 保护硬件状态寄存器等轻量、快速访问的数据
    struct mutex data_lock; // 保护需要长时间操作或可能睡眠的数据处理
    struct work_struct data_work; // 延迟处理工作项
    struct workqueue_struct *workqueue; // 私有工作队列
    void *pending_data;
    // ...
};

static irqreturn_t er2026_irq_handler(int irq, void *dev_id)
{
    struct er2026_device *dev = dev_id;
    unsigned long flags;
    u32 status;

    // 1. 快速读取状态，使用自旋锁保护（在RT中，这仍是安全的轻量级操作）
    spin_lock_irqsave(&dev->status_lock, flags);
    status = ioread32(dev->mmio_base + STATUS_REG);
    iowrite32(0, dev->mmio_base + STATUS_REG); // 清中断
    spin_unlock_irqrestore(&dev->status_lock, flags);

    // 2. 判断是否需要复杂处理
    if (status & DATA_READY_MASK) {
        // 3. 将耗时/可能睡眠的操作推送到工作队列（进程上下文）
        queue_work(dev->workqueue, &dev->data_work);
    }

    return IRQ_HANDLED;
}

// 工作队列处理函数，在进程上下文运行，可以安全睡眠
static void er2026_data_work_handler(struct work_struct *work)
{
    struct er2026_device *dev = container_of(work, struct er2026_device, data_work);

    // 使用互斥锁保护共享数据区
    mutex_lock(&dev->data_lock);
    // 现在可以安全地使用 GFP_KERNEL 分配内存
    dev->pending_data = kmalloc(BUFFER_SIZE, GFP_KERNEL);
    if (dev->pending_data) {
        // ... 从硬件读取数据（这里可能涉及慢速I/O） ...
        // ... 处理数据 ...
    }
    mutex_unlock(&dev->data_lock);
}

// 驱动初始化时创建互斥锁、自旋锁和工作队列
static int er2026_probe(struct platform_device *pdev)
{
    // ...
    spin_lock_init(&dev->status_lock);
    mutex_init(&dev->data_lock);
    INIT_WORK(&dev->data_work, er2026_data_work_handler);
    dev->workqueue = alloc_ordered_workqueue(“er2026_wq”, WQ_MEM_RECLAIM);
    // ...
}

修复要点 ：

  1. 职责分离 ： 中断处理函数只做最紧急的事情（读状态、清中断），绝不做可能阻塞的操作。复杂的数据处理通过工作队列（或任务队列、线程化中断本身）延迟到进程上下文执行。
  2. 锁的选型 ：
    • spinlock_t : 用于保护非常短小的、仅在中斷上下文或进程上下文快速访问的变量（如硬件状态寄存器）。即使在RT内核，对于极短的临界区也是合适的。
    • struct mutex : 用于保护需要长时间持有或操作可能睡眠的共享资源（如数据缓冲区链表）。这是进程上下文同步的首选。
  3. 内存分配标志 ： 在进程上下文中，使用 GFP_KERNEL ；如果必须在原子上下文（如真正的软中断、定时器回调）中分配内存，则使用 GFP_ATOMIC ，但应尽量避免。

4. 完整实战：为现有驱动添加RT兼容性检查与测试

假设你接手了一个传统驱动，需要评估其 PREEMPT_RT 兼容性。以下是系统化的步骤。

4.1 步骤一：静态代码分析

使用 sparse 和 coccinelle 等工具进行初步检查。 

# 在内核源码根目录，对驱动模块运行 sparse
make C=2 M=/path/to/your/driver/module
# 关注输出中的 “context” 相关警告，如 “in_interrupt” 等。

4.2 步骤二：动态检测与锁验证

启用内核的锁调试功能，这会在运行时检测潜在的锁滥用问题。 

# 配置内核时开启以下选项（通常在 make menuconfig -> Kernel hacking -> Lock Debugging 下）
CONFIG_PROVE_LOCKING=y      # 锁依赖证明，检测死锁可能
CONFIG_DEBUG_ATOMIC_SLEEP=y # 检测在原子上下文中睡眠
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y

重新编译并安装内核，加载你的驱动，进行压力测试。内核会在检测到违规时打印警告或Oops。

4.3 步骤三：压力测试与延迟监控

使用专门的实时性测试套件，在负载下观察驱动行为。 

# 使用 cyclictest 进行长时间延迟测试，并记录最大延迟
cyclictest -t -p 90 -n -i 1000 -l 1000000 -h 1000 > latency.log &
# 使用 stress-ng 制造系统压力
stress-ng --cpu 0 --io 2 --vm 1 --timeout 24h
# 使用 hackbench 进行进程/线程通信压力测试
hackbench -g 100 -l 100000

监控 dmesg 输出，并分析 latency.log 中的延迟分布。异常的延迟尖峰往往与驱动中的锁竞争或长时间关中断有关。

4.4 步骤四：使用 ftrace 进行性能剖析

如果驱动在压力下导致延迟增加，使用 ftrace 定位热点。 

# 启用函数跟踪
cd /sys/kernel/debug/tracing
echo function > current_tracer
echo 1 > tracing_on
# 运行你的测试负载...
echo 0 > tracing_on
# 查看跟踪结果，关注你的驱动函数耗时
cat trace | grep er2026 | head -20
# 更高级的，可以跟踪调度延迟或中断禁用时间
echo wakeup_rt > current_tracer # 跟踪实时任务唤醒延迟
echo irqsoff > current_tracer   # 跟踪中断被关闭的时间

5. 常见问题与排查思路（PREEMPT_RT专题）

问题现象 可能原因 排查思路与解决方案
“scheduling while atomic” Oops 在原子上下文（中断、软中断、持有自旋锁时）中调用了可能睡眠的函数（如 kmalloc(GFP_KERNEL) , mutex_lock , down_interruptible ）。 1. 分析Oops调用栈，定位违规函数。
2. 检查函数调用上下文：是否在中断处理函数、定时器回调、持有自旋锁的临界区内？
3. 修改：将耗时/可能睡眠的操作移到工作队列、任务队列或内核线程中。
系统在高负载下完全死锁 驱动中错误地嵌套使用了不同类型的锁（如自旋锁内获取互斥锁），或在 PREEMPT_RT 下错误理解了锁的语义导致循环等待。 1. 启用 CONFIG_PROVE_LOCKING ，内核可能提前报告锁依赖问题。
2. 审查所有锁的获取顺序，确保全局顺序一致。
3. 简化锁的设计，减少锁的粒度，避免嵌套。
实时任务延迟激增（Jitter） 驱动长时间关闭本地中断（ local_irq_save ）或持有自旋锁，阻塞了高优先级实时任务。 1. 使用 ftrace 的 irqsoff 跟踪器，找出中断被关闭最长的代码段。
2. 优化临界区：将无关操作移出临界区；将自旋锁换为互斥锁（如果上下文允许）；考虑使用 local_lock API（RT特有）来替代 local_irq_save 。
线程化中断处理程序性能下降 中断线程的优先级设置不当，或被其他相同优先级的线程阻塞。 1. 使用 `ps -eo pid,cls,rtprio,pri,nice,cmd
驱动在RT内核中初始化失败 驱动在 probe 函数中执行了在RT上下文中不允许的操作，或者依赖的另一个驱动/子系统尚未完成RT适配。 1. 检查 probe 函数中是否有在非进程上下文中的操作（如早期中断注册）。
2. 将初始化工作拆分，耗时的部分放入 deferred_probe 或工作队列。
3. 确认内核依赖选项，如 CONFIG_HIGH_RES_TIMERS 是否启用。

6. 最佳实践与工程建议

要让你的驱动或内核模块在标准内核和 PREEMPT_RT 内核下都能稳定运行，应遵循以下原则：

  1. 假设代码总是在抢占环境下运行 ： 即使你当前的目标内核是 PREEMPT_NONE ，也以 PREEMPT 或 PREEMPT_RT 的要求来编写同步代码。这能从根本上提高代码的健壮性。
  2. 明确区分上下文 ：
    • 原子上下文 ： 包括硬件中断（ request_irq ）、软中断（ tasklet , softirq ）、定时器回调（ timer_list ）。在这些上下文中， 绝不能睡眠 。只能使用自旋锁（ spinlock_t ）和 GFP_ATOMIC 内存分配。
    • 进程上下文 ： 包括系统调用、内核线程、工作队列（ workqueue ）。在这些上下文中， 可以睡眠 。优先使用互斥锁（ mutex ）、信号量（ semaphore ）和 GFP_KERNEL 内存分配。
  3. 慎用自旋锁，多用互斥锁 ： 除非临界区极短（如仅访问一个整型变量），否则在进程上下文中优先考虑互斥锁。自旋锁应主要用于保护在原子上下文和进程上下文之间共享的极小数据。
  4. 中断处理要短平快 ： 中断处理函数的黄金法则。使用 request_threaded_irq 或工作队列将中断下半部（bottom half）延迟处理。这是兼容 PREEMPT_RT 的标准做法。
  5. 使用正确的内存分配标志 ：
    • GFP_KERNEL : 标准分配，可能睡眠和进行内存回收。 仅用于进程上下文 。
    • GFP_ATOMIC : 原子分配，不会睡眠。用于 原子上下文 ，但可能因内存不足而失败。
    • GFP_NOWAIT : 类似于 GFP_ATOMIC ，但更温和，失败时返回 NULL 。
  6. 利用内核的锁调试和检测工具 ： 在开发阶段，务必开启 CONFIG_DEBUG_ATOMIC_SLEEP , CONFIG_PROVE_LOCKING 等选项。它们能以较小的性能代价，在运行时捕获大部分并发错误。
  7. 为实时任务预留CPU资源 ： 在 PREEMPT_RT 系统中，可以通过 isolcpus 内核参数隔离出专用的CPU核心，只运行高优先级实时任务和中断，避免被普通任务干扰。
  8. 设备树（Device Tree）配置的考量 ： 虽然设备树主要描述硬件，但在实时系统中，中断控制器（如GIC）的配置、DMA缓冲区的设置（如使用 CMA 区域）都可能影响确定性。确保硬件资源配置合理，避免共享资源成为瓶颈。

从ER2026的案例我们可以看到，内核抢占模式的升级不是简单的配置切换，它是对整个系统软件，特别是驱动代码质量的一次严格考验。主动以高抢占环境的标准来要求自己的代码，不仅能避免切换时的阵痛，更能从根本上提升软件的可靠性和可维护性。当你下次遇到那些“幽灵般”的随机故障时，不妨思考一下：这会不会是抢占机制在提醒你，某个角落里的锁用得不对，或者某个中断处理函数太长了？

Logo
openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

cover

1.nginx介绍和nginx的三种安装方式

avatar openEuler 社区
cover

学习笔记 Markdown 语法速查

avatar openEuler 社区

二、网络编程篇

最早诞生于 BSD4.2 系统，现在已经是所有操作系统网络编程的事实标准，socket 本质是内核提供的通信抽象，一个文件描述符，我们通过它发起连接、接收连接、读写收发缓冲区，完成 TCP 或者 UDP 的数据收发。前面一篇文章我们看懂了协议栈报文、三次握手四次挥手，本篇落到了系统调用和内核行为，抓包 和阅读内核行为，两者结合，socket 编程就不再是单纯背诵 API。偷看内核缓冲区数据，读取之

avatar openEuler 社区