当内核代码被中断时会发生什么？
我正在阅读《操作系统概念》（Silberschatz、Galvin、Gagne），第 6 版，第 20 章。 据我所知，Linux 内核代码是不可抢占的（2.6 版本之前）。但它可以被硬件中断打断。如果内核处于临界区中间并且发生中断并且它也执行了临界区，会发生什么？
从我在书中读到的：
第二种保护方案 Linux用途适用于关键 中断服务例程中出现的部分。基本工具是 处理器中断控制 硬件...
好吧，当 ISR 有临界区时使用此方案。但它只会禁用进一步的中断。首先被这个中断中断的内核代码怎么样？
I am reading Operating System Concepts (Silberschatz,Galvin,Gagne), 6th edition, chapter 20.
I understand that Linux kernel code is non preemptible (before 2.6 version). But it can be interrupted by hardware interrupts. What happens if the kernel was in the middle of a critical section and the interrupt occured and it too executed the critical section?
From what I read in the book:
The second protection scheme that
Linux uses applies to critical
sections that occur in the interrupt service routines. The basic tool is
the processor interrupt control
hardware...
Ok, this scheme is used when an ISR has a critical section. But it will only disble further interrupts. What about the kernel code which was interrupted by this interrupt in the first place?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果中断处理程序和其他内核代码需要访问相同的数据，您需要防止这种情况，这通常是通过 自旋锁，必须非常小心，你不想引入死锁，并且必须确保这样的自旋锁不会保持太久。对于硬件中断处理程序中使用的自旋锁，您必须在保持锁定的同时禁用该处理器上的中断 - 在 Linux 中这是通过函数 spin_lock_irqsave() 完成的。
（虽然有点过时，但您可以在此处了解该概念）
If the interrupt handler and other kernel code need access to the same data, you need to protect against that, which is usually done by a spinlock , great care must be taken, you don't want to introduce a deadlock ,and you must ensure such a spinlock is not held for too long. For spinlocks used in a hardware interrupt handler you have to disable interrupts on that processor whilst holding the lock - which in linux is done with the function spin_lock_irqsave().
(whilst a bit outdated, you can read about the concept here)
首先被该中断中断的内核代码被中断。
这就是为什么编写中断处理程序是一项如此痛苦的任务：它们不能做任何会危及主流执行的正确性的事情。
例如，Apple的xnu内核处理大多数类型的设备中断的方式是将中断中的信息捕获到内存中的记录中，将该记录添加到队列中，然后恢复正常执行；然后内核在一段时间后从队列中获取中断（我假设在调度程序的主循环中）。这样，中断处理程序仅通过中断队列与系统的其余部分交互，并且几乎不存在引起麻烦的危险。
有一点中间立场；在许多体系结构（包括 x86）上，特权代码可以屏蔽中断，这样它们就不会导致中断。这可以用来保护确实不应该被中断的代码段落。然而，这些架构通常也具有不可屏蔽中断，它们会忽略屏蔽，因此仍然需要考虑中断。
The kernel code which was interrupted by this interrupt in the first place gets interrupted.
This is why writing interrupt handlers is such a painful task: they can't do anything that would endanger the correctness of the main stream of execution.
For example, the way Apple's xnu kernel handles most kinds of device interrupts is to capture the information in the interrupt to a record in memory, add that record to a queue, and then resume normal execution; the kernel then picks up interrupts from the queue some time later (in the scheduler's main loop, i assume). That way, the interrupt handler only interacts with the rest of the system through the interrupt queue, and there is little danger of it causing trouble.
There is a bit of middle ground; on many architectures (including the x86), it is possible for privileged code to mask interrupts, so that they won't cause interruption. That can be used to protect passages of code which really shouldn't be interrupted. However, those architectures typically also have non-maskable interrupts, which ignore the masking, so interruption still has to be considered.