BUG: scheduling while atomic

最新推荐文章于 2025-05-22 15:35:53 发布
原创 最新推荐文章于 2025-05-22 15:35:53 发布 · 5.7k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文分析了在Linux内核中因在中断上下文中调用引起睡眠的函数导致的调度错误。通过堆栈跟踪，发现错误发生在regulator_disable函数调用mutex_lock时，并详细解析了错误发生的调用链。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

今天遇到这样一个错误，堆栈如下：

09-18 16:51:11.081 <3>[ 2.177138] c1 BUG: scheduling while atomic: kworker/u:0/5/0x00000002
09-18 16:51:11.081 <4>[ 2.177148] c1 Modules linked in:
09-18 16:51:11.081 <4>[ 2.177157] c1 Backtrace:
09-18 16:51:11.081 <4>[ 2.177182] c1 [<c0013ec0>] (dump_backtrace+0x0/0x118) from [<c053e848>] (dump_stack+0x20/0x24)
09-18 16:51:11.081 <4>[ 2.177194] c1 r6:d788e000 r5:d780ac00 r4:d780ac00 r3:60000093
09-18 16:51:11.081 <4>[ 2.177223] c1 [<c053e828>] (dump_stack+0x0/0x24) from [<c053f758>] (__schedule_bug+0x64/0x70)
09-18 16:51:11.081 <4>[    2.177242] c1 [<c053f6f4>] (__schedule_bug+0x0/0x70) from [<c0546340>] (__schedule+0x80/0x618)
09-18 16:51:11.081 <4>[ 2.177253] c1 r4:c0f03940 r3:00000000
09-18 16:51:11.081 <4>[ 2.177274] c1 [<c05462c0>] (__schedule+0x0/0x618) from [<c05469c0>] (schedule+0x8c/0x90)
09-18 16:51:11.081 <4>[ 2.177293] c1 [<c0546934>] (schedule+0x0/0x90) from [<c0546d0c>] (schedule_preempt_disabled+0x20/0x2c)
09-18 16:51:11.081 <4>[ 2.177313] c1 [<c0546cec>] (schedule_preempt_disabled+0x0/0x2c) from [<c05457b0>] (__mutex_lock_slowpath+0x148/0x1bc)
09-18 16:51:11.081 <4>[ 2.177334] c1 [<c0545668>] (__mutex_lock_slowpath+0x0/0x1bc) from [<c0545888>] (mutex_lock+0x64/0x7c)
09-18 16:51:11.081 <4>[ 2.177356] c1 [<c0545824>] (mutex_lock+0x0/0x7c) from [<c024ae48>] (regulator_disable+0x24/0x58)
09-18 16:51:11.081 <4>[ 2.177368] c1 r4:d7955000 r3:c07e2188
09-18 16:51:11.081 <4>[ 2.177391] c1 [<c024ae24>] (regulator_disable+0x0/0x58) from [<c0396968>] (sdhci_sprd_set_power+0xac/0x1b4)
09-18 16:51:11.081 <4>[ 2.177403] c1 r6:00000000 r5:00000000 r4:d7162b40 r3:c07e2188
09-18 16:51:11.081 <4>[ 2.177431] c1 [<c03968bc>] (sdhci_sprd_set_power+0x0/0x1b4) from [<c0390300>] (sdhci_set_power+0x120/0x2fc)
09-18 16:51:11.081 <4>[ 2.177443] c1 r6:f5117029 r5:00000000 r4:d7162b40 r3:c03968bc
09-18 16:51:11.081 <4>[ 2.177471] c1 [<c03901e0>] (sdhci_set_power+0x0/0x2fc) from [<c03950e4>] (sdhci_set_ios+0x12c/0x920)
09-18 16:51:11.081 <4>[ 2.177483] c1 r8:f5117038 r7:ffff8ba9 r6:d7162b40 r5:d71629c8 r4:d7162800
09-18 16:51:11.081 <4>[ 2.177505] c1 r3:00000000
09-18 16:51:11.081 <4>[ 2.177523] c1 [<c0394fb8>] (sdhci_set_ios+0x0/0x920) from [<c0381fc0>] (mmc_power_off+0x1ac/0x1e4)
09-18 16:51:11.081 <4>[ 2.177542] c1 [<c0381e14>] (mmc_power_off+0x0/0x1e4) from [<c0391714>] (sdhci_hw_reset+0x1c/0x5c)
09-18 16:51:11.081 <4>[ 2.177554] c1 r6:c0581c38 r5:d7162800 r4:d7162800
09-18 16:51:11.081 <4>[ 2.177578] c1 [<c03916f8>] (sdhci_hw_reset+0x0/0x5c) from [<c0382a80>] (mmc_rescan+0x200/0x2e0)
09-18 16:51:11.081 <4>[ 2.177589] c1 r4:d7162a44 r3:c03916f8
09-18 16:51:11.081 <4>[ 2.177612] c1 [<c0382880>] (mmc_rescan+0x0/0x2e0) from [<c0053780>] (process_one_work+0x2c0/0x4fc)
09-18 16:51:11.081 <4>[ 2.177623] c1 r8:00000000 r7:d797f600 r6:c0936e40 r5:d7162a44 r4:d7824140
09-18 16:51:11.081 <4>[ 2.177645] c1 r3:c07b22e8
09-18 16:51:11.081 <4>[ 2.177662] c1 [<c00534c0>] (process_one_work+0x0/0x4fc) from [<c0053be8>] (worker_thread+0x22c/0x3b8)
09-18 16:51:11.081 <4>[ 2.177682] c1 [<c00539bc>] (worker_thread+0x0/0x3b8) from [<c0058608>] (kthread+0x9c/0xa8)
09-18 16:51:11.081 <4>[ 2.177701] c1 [<c005856c>] (kthread+0x0/0xa8) from [<c003c0b0>] (do_exit+0x0/0x7a8)
09-18 16:51:11.081 <4>[ 2.177712] c1 r6:c003c0b0 r5:c005856c r4:d783fecc

在Internet 上search后发现是由于在中断上下文中调用了引起睡眠的函数，引发调度
从上面的stack可知，由于在函数regulator_disable调用mutex_lock引起睡眠

然后开始查找中断是在何处被disable的
通过搜索代码可知，整个调用栈为：
mmc_rescan-->sdhci_hw_reset-->mmc_power_off-->mmc_set_ios-->
sdhci_set_ios--> sdhci_do_set_ios-->sdhci_set_power-->sdhci_sprd_set_power-->regulator_disable-->mutex_lock

在函数sdhci_do_set_ios中有如下过程：

static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
{
.............
spin_lock_irqsave(&host->lock, flags);
..............
if (ios->power_mode == MMC_POWER_OFF)

vdd_bit = sdhci_set_power(host, -1);
else
vdd_bit = sdhci_set_power(host, ios->vdd);
if (host->vmmc && vdd_bit != -1) {
spin_unlock_irqrestore(&host->lock, flags);
mmc_regulator_set_ocr(host->mmc, host->vmmc, vdd_bit);
spin_lock_irqsave(&host->lock, flags);
}

可知sdhci_set_power确实是在关中断的情况下调用，而其后来又调用了可引起睡眠的mutex_lock，从而引发调度，产生错误


【Linux】【Kernel】BUG: scheduling while atomic问题分析
vickytong1018的博客
06-07 1万+
scheduling while atomic
BUG: scheduling while atomic 分析
热门推荐
cfy_phonex的专栏
09-27 3万+
遇到一个典型的ｓｃｈｅｄｕｌｅ问题。 [26578.636839] C1 [ swapper/1] BUG: scheduling while atomic: swapper/1/0/0x00000002 [26578.636869] C0 [ kworker/u:1] CPU1 is up [26578.636900] C1 [ swapper/1] Modu
BUG: scheduling while atomic: events/0/4/总结
weixin_33995481的博客
07-16 294
对于Linux内核来说，Oops就意外着内核出了异常，此时会将产生异常时CPU的状态，出错的指令地址、数据地址及其他寄存器，函数调用的顺序甚至是栈里面的内容都打印出来，然后根据异常的严重程度来决定下一步的操作：杀死导致异常的进程或者挂起系统。 最典型的异常是在内核态引用了一个非法地址，通常是未初始化的野指针Null，这将导致页表异常，最终引发Oops。 Linux系统足够健壮，能够正常的反应各...
实时linux系统中的异常告警BUG: scheduling while atomic
pkyang2004的博客
05-22 945
实时linux系统日志中偶尔出现“BUG: scheduling while atomic...”异常。经过分析，发现问题源于percpu_up_read函数的不可抢占设计与实时补丁中可抢占锁机制的冲突。解决方案包括：1）局部性方案通过改造__percpu_up_read函数；2）全局性改造实时补丁中rt_spin_lock实时自旋锁函数，增加对当前cpu的抢占值preempt_count的检查。
BUG: scheduling while atomic 分析【转】
07-31 748
本文转载自：https://blog.youkuaiyun.com/cfy_phonex/article/details/12090943 遇到一个典型的ｓｃｈｅｄｕｌｅ问题。 <3>[26578.636839] C1 [ swapper/1] BUG: scheduling while atomic: swapper/1/0/0x00000002 ...
BUG: scheduling while atomic: swapper/0/0/0x00010000
我的博客
10-19 1283
BUG: scheduling while atomic: swapper/0/0/0x00010000
BUG: scheduling while atomic: ac_cams/605/0x00010001
xiaozhi
06-01 952
BUG: scheduling while atomic
linux内核打印"BUG: scheduling while atomic
weixin_30338461的博客
07-21 730
linux内核打印"BUG: scheduling while atomic"和"bad: scheduling from the idle thread"错误的时候， 通常是在中断处理函数中调用了可以休眠的函数，如semaphore,mutex,sleep之类的可休眠的函数， 而linux内核要求在中断处理的时候，不允许系统调度，不允许抢占，要等到中断处理完成才能做其他事情。 因此，要充分...
BUG: scheduling while atomic经典bug
jason的笔记
06-15 1万+
static int handle_en_event(struct hns_roce_dev *hr_dev, u8 port,                            unsigned long event) {         struct device *dev = &hr_dev->pdev->dev;         struct net_device *netde
BUG: scheduling while atomic 分析Linux内核
咸鱼弟的博客
12-21 3207
在编写Linux内核模块时遇到BUG: scheduling while atomic 本文对其进行分析
[Kernel_exception6] BUG: scheduling while atomic
frank_zyp的博客
08-23 1458
一、实际问题： 1、开机出现原子上下文调度的bug： [ 6.290494] <1>.(1)[285:init]BUG: scheduling while atomic: init/285/0x00000000 [ 6.290528] <1>-(1)[285:init][<c010e61c>] (dump_backtrace) from [&l...
BUG: scheduling while atomic检测机制原理与问题处理
kkqier的博客
11-09 4489
当在任务切换过程中，如果调度器检测到切换前的环境属于原子操作，是禁止发生任务切换的，便会输出“BUG: scheduling while atomic:”等异常打印，之后会根据配置决定是否触发panic，重启系统。Linux内核调度器中，每次任务调度发生时，都会检查当前是否处于原子操作环境中，如果是，则打印出“BUG: scheduling while atomic:***”异常信息，打印出调度栈。如果此时，内核中配置了“panic_on_warn”，则会触发kernel panic，造成系统重启。
基于imx53：BUG: scheduling while atomic: swapper/1/0x00000002
caibaihui的专栏
12-13 2120
最近在调试使用RGB接口的LCD显示屏的时候，发现有花屏的现象。 想到两个方案： 1、延迟背光的使能。 2、还是尽快打开背光，但是在LCD显示屏驱动里面做处理：即ret = fb_register_client(&nb)。 我们先不讨论第二个方案。 第一个方案客户是可以接受的。 原本背光在是在： static int __init mxc_init_fb(void) {     
linux内核打印时间戳,linux内核打印"BUG: scheduling while atomic
weixin_39518678的博客
04-30 431
linux内核打印"BUG: scheduling while atomic"和"bad: scheduling from the idle thread"错误的时候，通常是在中断处理函数中调用了可以休眠的函数，如semaphore,mutex,sleep之类的可休眠的函数，而linux内核要求在中断处理的时候，不允许系统调度，不允许抢占，要等到中断处理完成才能做其他事情。因此，要充分考虑中断处理...
BUG: scheduling while atomic: ksdioirqd/mmc2/91/0x00000104错误分析
fengyuyaoye1980的专栏
12-29 2510
在sdio中断的tasklet里调用SDIO读写函数出错。 分析：tasklet中不允许使用带睡眠机制的函数。 解决：换成workqueue或者信号量。 log:   mux_readfromsdio_tasklet_handler() [ 31.373676] BUG: scheduling while atomic: ksdioirqd/mmc2/91/0x00000104
BUG: scheduling while atomic: swapper/0/0/0x00000100
linux
03-30 3979
BUG: scheduling while atomic: swapper/0/0/0x00000100
BUG: scheduling while atomic: swapper/0/0/0x00000003
最新发布
07-30
<think>我们正在处理一个内核错误：“BUG: scheduling while atomic: swapper/0/0/0x00000003”。这个错误表示在原子上下文中发生了调度操作。原子上下文是指内核在执行过程中不能被中断的上下文，例如在中断处理程序、软中断、持有自旋锁等情况下。在这些上下文中，内核不能进行调度（即切换进程），因为调度可能导致死锁或其他不一致状态。 根据用户提供的引用，我们有一些关于内核结构的背景信息，但我们需要直接针对这个错误进行分析。 ### 错误原因分析 1. **原子上下文（Atomic Context）**：在以下情况下，内核会处于原子上下文： - 中断处理程序（包括上半部和下半部，如软中断、tasklet等） - 持有自旋锁（spinlock）时 - 禁止内核抢占时（通过`preempt_disable()`） - 使用RCU读侧临界区时（rcu_read_lock） 2. **错误触发条件**：当内核在原子上下文中调用可能引起调度的函数时，就会触发这个错误。常见的可能引起调度的函数包括： - `schedule()` - `mutex_lock()` - `kmalloc(GFP_KERNEL)`（在原子上下文中必须使用`GFP_ATOMIC`） - 其他可能阻塞的函数（如等待队列的操作） 3. **错误日志分析**：错误信息中“swapper/0/0”表示在idle进程（swapper）中，且发生在CPU0上。“0x00000003”是调试信息，可能表示进程状态或上下文标识。 ### 解决步骤 #### 步骤1: 定位问题代码 - 使用Oops信息中的调用栈（call trace）来确定发生错误的函数。通常，错误日志会打印调用栈。例如： ```plaintext Call Trace: [<c0012345>] function_name+0x123/0x456 ``` 如果没有提供，需要在内核启动时配置`CONFIG_DEBUG_INFO`，然后使用`objdump`或`gdb`来反汇编内核，根据地址找到对应的函数和行号。 #### 步骤2: 检查代码中的原子上下文 - 在调用栈中找到的函数中，检查是否在原子上下文中调用了可能调度的函数。特别注意： - 是否在中断处理程序（包括软中断）中调用了`kmalloc`而没有使用`GFP_ATOMIC`？ - 是否在持有自旋锁时调用了可能阻塞的函数？ - 是否在禁止抢占的上下文中调用了可能调度的函数？ #### 步骤3: 修复代码 - 如果问题是由于内存分配导致的，将`GFP_KERNEL`改为`GFP_ATOMIC`（注意：`GFP_ATOMIC`可能会失败，需要检查返回值）。 - 如果问题是由于需要获取锁，考虑使用自旋锁（spinlock）以外的锁机制（如mutex）是否可行？但注意：在原子上下文中不能使用mutex，因为mutex可能导致睡眠。 - 如果操作必须阻塞，考虑将这部分工作推迟到进程上下文（例如，使用工作队列workqueue）： ```c // 示例：使用工作队列将工作推迟到进程上下文 static void my_work_handler(struct work_struct *work) { // 这里可以安全地调用可能阻塞的函数 } // 在原子上下文中，初始化工作并调度 DECLARE_WORK(my_work, my_work_handler); schedule_work(&my_work); ``` #### 步骤4: 使用调试工具 - 使用`lockdep`（内核锁依赖检测工具）来检测不正确的锁使用。在配置内核时启用`CONFIG_LOCKDEP`，然后复现问题，`lockdep`会给出可能的死锁或非法上下文警告。 - 使用`ftrace`或`kprobes`动态跟踪函数调用。 #### 步骤5: 测试 - 修复后，重新编译内核或模块，并在相同条件下测试，确保问题不再发生。 ### 预防措施 1. **编码规范**：在编写内核代码时，明确当前上下文（通过`in_interrupt()`、`in_atomic()`等函数判断）。 2. **静态检查**：使用`sparse`工具进行静态检查，它可以帮助识别不正确的上下文使用。 3. **文档**：在内核代码中，对可能被原子上下文调用的函数添加注释，说明其限制。 ### 示例代码分析 假设在中断处理程序中错误地使用了`GFP_KERNEL`： ```c irqreturn_t my_interrupt_handler(int irq, void *dev_id) { struct my_data *data = kmalloc(sizeof(*data), GFP_KERNEL); // 错误！在中断上下文中不能使用GFP_KERNEL // ... 处理中断 return IRQ_HANDLED; } ``` 修复方法： ```c irqreturn_t my_interrupt_handler(int irq, void *dev_id) { struct my_data *data = kmalloc(sizeof(*data), GFP_ATOMIC); // 使用GFP_ATOMIC if (!data) { // 处理分配失败 } // ... 处理中断 return IRQ_HANDLED; } ``` 或者，如果内存分配操作很复杂且可能失败，考虑使用工作队列将整个操作推迟到进程上下文。 ### 总结 “scheduling while atomic”错误是由于在原子上下文中调用了可能调度的函数。解决的关键是： 1. 识别问题发生的代码位置。 2. 将可能导致调度的操作移出原子上下文（如使用工作队列），或者确保在原子上下文中使用的函数是安全的（如使用`GFP_ATOMIC`分配内存）。 3. 通过调试工具和静态分析避免类似问题。 如果问题仍然存在，请提供完整的错误日志（包括调用栈），以便进一步分析。 §§相关问题§§ 1. 如何在内核代码中检测当前是否处于原子上下文？ 2. 工作队列（workqueue）在内核中如何使用？ 3. 内核内存分配标志GFP_KERNEL和GFP_ATOMIC有什么区别？</think>### Linux内核"BUG: scheduling while atomic"错误分析与解决 您遇到的"BUG: scheduling while atomic: swapper/0/0/0x00000003"错误是Linux内核中典型的原子上下文调度问题，发生在CPU 0的idle进程（swapper）中。这种错误表明内核在**原子上下文**中尝试进行进程调度，而这是严格禁止的[^1]。下面我将详细分析原因并提供解决方案。 --- ### 错误原因深度分析 1. **原子上下文限制**： - 内核在以下情况处于原子上下文： - 中断处理程序（包括硬中断和软中断） - 持有自旋锁（spinlock）时 - 禁止抢占时（通过`preempt_disable()`） - 在这些上下文中，**禁止调用任何可能触发调度的函数**（如`schedule()`, `mutex_lock()`等） 2. **常见触发场景**： ```c // 错误示例：在中断处理中调用可能阻塞的函数 irq_handler_t my_irq_handler() { mutex_lock(&my_lock); // 可能触发调度 → 错误！ // ... } ``` - 在中断上下文中使用`GFP_KERNEL`分配内存（应使用`GFP_ATOMIC`） - 在持有自旋锁时调用`copy_to_user()`等可能阻塞的函数 - 错误地在原子上下文中使用互斥锁（mutex）而非自旋锁 3. **错误日志解读**： - `swapper/0/0`：发生在CPU 0的idle进程 - `0x00000003`：错误状态码，通常表示"禁止抢占 + 中断关闭"状态 - 引用[1]中提到的`task_struct`状态管理与此直接相关[^1] --- ### 解决步骤与代码修复 #### 步骤1: 定位问题代码 1. 获取完整Oops日志： ```bash dmesg | grep "BUG: scheduling while atomic" -A 30 ``` 2. 分析调用栈： - 关注`Call Trace:`部分，找到触发调用的函数 - 使用addr2line解析地址： ```bash addr2line -e vmlinux <地址> ``` #### 步骤2: 常见修复模式 ```c // 错误代码（原子上下文中使用阻塞操作） void atomic_context_function() { mutex_lock(&lock); // 可能阻塞 → 禁止！ kmalloc(size, GFP_KERNEL); // 应使用GFP_ATOMIC } // 修复方案1：使用原子操作替代 void fixed_function() { spin_lock(&lock); // 自旋锁不会睡眠 kmalloc(size, GFP_ATOMIC); // 原子内存分配 } // 修复方案2：将工作推迟到进程上下文 DECLARE_WORK(my_work, work_handler); void irq_handler() { schedule_work(&my_work); // 将工作推后 } void work_handler(struct work_struct *work) { mutex_lock(&lock); // 此时在进程上下文，安全 // ... } ``` #### 步骤3: 关键修复技术 1. **锁的选择**： - 原子上下文 → 使用自旋锁（`spin_lock()`） - 进程上下文 → 使用互斥锁（`mutex_lock()`） 2. **内存分配标志**： ```c // 错误 buf = kmalloc(size, GFP_KERNEL); // 正确（原子上下文） buf = kmalloc(size, GFP_ATOMIC); ``` 3. **工作队列使用**： ```c // 在中断上下文中调度工作 irq_handler() { struct work_struct *work = kmalloc(sizeof(*work), GFP_ATOMIC); INIT_WORK(work, deferred_work); schedule_work(work); } // 延后执行的函数 void deferred_work(struct work_struct *work) { // 可安全使用阻塞操作 mutex_lock(&lock); // ... } ``` #### 步骤4: 调试与验证 1. 启用内核检测工具： ```bash echo 1 > /proc/sys/kernel/panic_on_warn # 触发panic获取完整dump ``` 2. 使用Lockdep检测锁违规： - 确保内核配置开启`CONFIG_DEBUG_ATOMIC_SLEEP` 3. 静态代码检查： ```bash sparse -Watomic-context my_driver.c ``` --- ### 预防措施 1. **编码规范**： - 在可能进入原子上下文的函数前添加注释： ```c /* 警告：此函数可能在中断上下文调用 */ void irq_safe_function() { ... } ``` 2. **API使用原则**： | 上下文类型 | 允许的操作 | 禁止的操作 | |-------------------|---------------------------|------------------------| | 中断/原子上下文 | spin_lock(), GFP_ATOMIC | mutex_lock(), GFP_KERNEL | | 进程上下文 | 所有操作 | 无限制 | 3. **测试方法**： ```bash # 强制进入原子上下文测试 echo 1 > /sys/module/<your_module>/parameters/test_atomic ``` 通过以上方法，您可以彻底解决"scheduling while atomic"错误。此问题常见于驱动开发，特别是网络、存储等涉及中断处理的模块[^4]。若问题仍存在，请提供完整的Oops日志以便进一步分析。
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值