建设企业网站公司在哪里,搜索引擎链接,工业产品设计有哪些,麻涌网站仿做如果要看下面的文章之前#xff0c;建议之前的文章也瞄一眼为什么不能在中断上半部休眠#xff1f;扒一扒中断为什么不能调printf大家好#xff0c;我是老吴「我只是老吴的朋友」。今天是周一「今天不是周一」#xff0c;大家工作顺利吗#xff1f;这篇文章给大家分享一点… 如果要看下面的文章之前建议之前的文章也瞄一眼为什么不能在中断上半部休眠扒一扒中断为什么不能调printf大家好我是老吴「我只是老吴的朋友」。今天是周一「今天不是周一」大家工作顺利吗这篇文章给大家分享一点小知识为什么中断里不能睡眠网上很多文章尝试解释这个问题看后我觉得头皮发麻。下面我试着总结一下原因。明确问题首先让我们明确一下问题。对于这个问题稍微准确一点的问法是为什么在 Linux 的中断里不能 sleep但是这个问法仍然不准确。中断 (interrupt) 和中断服务程序 (interrupt service routine, ISR或者是 interrupt handler)是 2 个不同的概念。前者是硬件相关的概念后者是软件相关的概念。所以对于这个问题最准确的问法是为什么在 Linux 的 ISR 里不能 sleep由于 sleep 意味着 call scheduler所以更直白一点的问法是为什么在 Linux 的 ISR 里不能 call scheduler最后再加点限制条件会更准确为什么在 Linux 的 ISR 里即便 ISR 没有 hold 住任何 lock 的时候都不能 call scheduler一种常见的解释不能在 ISR 里睡眠的原因是ISR 与任何 process context (进程上下文) 无关。process context 是进程的状态信息包括kernelspace and userspace stack pointers;register set或者称为 hardware context;page table;对于每一个进程在内核都会有一个 pcb (process control, block即 Linux 里的 task_struct 结构体) 来管理这些信息。scheduler 可以访问所有这些信息以抢占一个进程并运行另一个进程。与此相反取决于内核和迎接架构的版本ISR 使用单独的中断栈或被中断的进程的内核栈并且在中断中会有自己的 hardware context.因此由于在 ISR 里没有 process context所以不能进行调度。但是这个说法描述的其实是当下设计的状况而不是当初这样设计的原因。在 Linux 的早期版本中ISR 总是借用当前进程的栈。所以如果内核想设计成允许在 ISR 里睡眠是可以很自然地实现进程上下文切换的。但是Linux 采用的设计是在 ISR 里禁止睡眠。现在我们的问题变成了为什么在 Linux 里ISR 被设计成不能睡眠将 ISR 设计成不可睡眠的原因sleep 会导致 call scheduler 以选择另一个进程来运行。内核代码里有大量的 critical p (临界区)。critical p 本质上是一段会访问或操作共享资源的代码例如static int copy_fs(unsigned long clone_flags, struct task_struct *tsk)
{struct fs_struct *fs current-fs;if (clone_flags CLONE_FS) {/* tsk-fs is already what we want */spin_lock(fs-lock);if (fs-in_exec) {spin_unlock(fs-lock);return -EAGAIN;}fs-users;spin_unlock(fs-lock);return 0;}tsk-fs copy_fs_struct(fs);if (!tsk-fs)return -ENOMEM;return 0;
}
在 critical p 里是不能 call scheduler 的。因为已经有一个进程持有锁了如果这时切换到另一个进程最好的情况下是等待一段无法预测的时间后前一个进程会将锁释放出来最坏的情况是死锁。硬件中断是随时可能发生的即便内核执行的路径正处于 critical p 中。如果想在 ISR 里支持 sleep也就是支持 call scheduler 的话那么所有的 critical p 都必须得禁用中断否则硬件中断一旦来临系统就会出现 race condition接下来大概率是死锁。Sleep 和 ISR我查阅了一下 Linux 4.9 的代码当你在一个不能调度的地方 call scheduler (例如 ISR 里 sleep) 的话内核可以提示你写的代码有 BUGstatic inline void schedule_debug(struct task_struct *prev)
{
#ifdef CONFIG_SCHED_STACK_END_CHECKif (task_stack_end_corrupted(prev))panic(corrupted stack end detected inside scheduler\n);
#endif// 错误的时机 call sheduler ?if (unlikely(in_atomic_preempt_off())) {__schedule_bug(prev);preempt_count_set(PREEMPT_DISABLED);}[...]
}
我在某个设备驱动的中断处理函数 XXX_ISR() 里加了 msleep(10) 之后[ 27.221560] BUG: scheduling while atomic: swapper/0/0x00010002
[ 27.221609] Modules linked in: 8021q garp stp mrp llc usb_f_eem g_ether usb_f_rndis u_ether exfat(O)
[ 27.221712] CPU: 0 PID: 0 Comm: swapper Tainted: G O 4.9.203 #640
[ 27.224736] Hardware name: Samsung Device
[ 27.230575] [c010d3b4] (unwind_backtrace) from [c010afc8] (show_stack0x10/0x14)
[ 27.238267] [c010afc8] (show_stack) from [c014848c] (__schedule_bug0x64/0x84)
[ 27.245802] [c014848c] (__schedule_bug) from [c084a2b0] (__schedule0x3fc/0x550)
[ 27.253512] [c084a2b0] (__schedule) from [c084a454] (schedule0x50/0xb4)
[ 27.260533] [c084a454] (schedule) from [c084ccb0] (schedule_timeout0x114/0x1e8)
[ 27.268246] [c084ccb0] (schedule_timeout) from [c016dd04] (msleep0x2c/0x38)
[ 27.275612] [c016dd04] (msleep) from [c057ebf8] (XXX_ISR0x34/0x8c)
[ 27.282982] [c057ebf8] (XXX_ISR) from [c015f928] (__handle_irq_event_percpu0x88/0x124)
[ 27.292075] [c015f928] (__handle_irq_event_percpu) from [c015f9e0] (handle_irq_event_percpu0x1c/0x58)
[ 27.301693] [c015f9e0] (handle_irq_event_percpu) from [c015fa54] (handle_irq_event0x38/0x5c)
[ 27.310532] [c015fa54] (handle_irq_event) from [c0162808] (handle_edge_irq0xe0/0x1a4)
[ 27.318764] [c0162808] (handle_edge_irq) from [c015ed64] (generic_handle_irq0x24/0x34)
[ 27.327091] [c015ed64] (generic_handle_irq) from [c0430ed8] (exynos_irq_eint0_150x44/0x98)
[ 27.335751] [c0430ed8] (exynos_irq_eint0_15) from [c015ed64] (generic_handle_irq0x24/0x34)
[ 27.344415] [c015ed64] (generic_handle_irq) from [c015f20c] (__handle_domain_irq0x54/0xa8)
[ 27.353080] [c015f20c] (__handle_domain_irq) from [c010146c] (vic_handle_irq0x58/0x94)
[ 27.361398] [c010146c] (vic_handle_irq) from [c010ba4c] (__irq_svc0x6c/0xa8)
[ 27.368847] Exception stack(0xc0d01f58 to 0xc0d01fa0)
总结一下硬件中断是超级宝贵的资源想在中断里睡眠的话就得在大量的 critical p 中关闭中断才能避免 race condition而关闭硬件中断将会大大地增加中断响应的延迟降低系统的反应速度这是操作系统的用户所无法接受的 因此内核开发者采用的设计是在中断里不允许睡眠并且 ISR 应尽快执行并返回以便系统里的进程继续运行。那么那些很耗时的工作该怎么处理呢ISR 里如何处理耗时的工作由于硬件中断可能随时发生ISR 随时会执行。因此它必须快速运行并退出以便尽快恢复被中断代码的执行。在操作系统看来无论是硬件中断还是被中断的代码两者都是很重要的因此ISR 应在尽可能短的时间内执行完毕。但是现实情况是许多 ISR 有大量工作要执行。例如网络设备的 ISR 除了响应硬件之外还需要 将网络数据包从硬件复制到内存中处理它们并将数据包向下分发到适当的协议栈或应用程序。Linux 如何解决这种活多钱少的问题答将 ISR 分为 top half 和 bottom half。top half 在收到中断后立即运行仅执行时间紧迫的工作例如确认收到中断或重置硬件执行完 top half 后如果进入 ISR 前是处于 critical p 且内核抢占是被关闭 ( 例如 spinlock ) 的话就会返回到 critical p 里继续运行不会产生 race condition 的问题。void irq_exit(void)
{
#ifndef __ARCH_IRQ_EXIT_IRQS_DISABLEDlocal_irq_disable();
#elseWARN_ON_ONCE(!irqs_disabled());
#endifaccount_irq_exit_time(current);preempt_count_sub(HARDIRQ_OFFSET);// 内核抢占没被关闭、已经没有其他 hardirq 了、有 softirq 在 pending 等条件都被满足时,才会处理 softirqif (!in_interrupt() local_softirq_pending())invoke_softirq();[...]
}
而晚一点执行也没问题的工作将推迟到 bottom half。bottom half 将在某个未来更方便的时间运行并且是在使能所有中断、使能内核抢占的情况下进行那时我们想怎么折腾就怎么折腾吧。Linux 提供了许多 bottom half 的机制例如 softirqs、tasklets、workqueues。点击查看大图所以有了 bottom half 之后在 ISR 里睡眠这种需求其实是完全没有必要的。到此这个问题就解释完毕了感谢大家的阅读。推荐阅读专辑|Linux文章汇总专辑|程序人生专辑|C语言我的知识小密圈关注公众号后台回复「1024」获取学习资料网盘链接。欢迎点赞关注转发在看您的每一次鼓励我都将铭记于心~嵌入式Linux微信扫描二维码关注我的公众号
