Linux 内核 --- 为什么在中断里不能 sleep

明确问题

首先，让我们明确一下问题。

对于这个问题，稍微准确一点的问法是：为什么在 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 section (临界区)。

critical section 本质上是一段会访问或操作共享资源的代码，例如：

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 section 里，是不能 call scheduler 的。

因为已经有一个进程持有锁了，如果这时切换到另一个进程，最好的情况下是等待一段无法预测的时间后前一个进程会将锁释放出来，最坏的情况是死锁。

硬件中断是随时可能发生的，即便内核执行的路径正处于 critical section 中。

如果想在 ISR 里支持 sleep，也就是支持 call scheduler 的话，那么所有的 critical section 都必须得禁用中断，否则硬件中断一旦来临系统就会出现 race condition，接下来大概率是死锁。

Sleep 和 ISR：

 查阅了一下 Linux 4.9 的代码，当你在一个不能调度的地方 call scheduler (例如 ISR 里 sleep) 的话，内核可以提示你写的代码有 BUG：

static inline void schedule_debug(struct task_struct *prev)
{
#ifdef CONFIG_SCHED_STACK_END_CHECK
 if (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_stack+0x10/0x14)
[   27.238267] [<c010afc8>] (show_stack) from [<c014848c>] (__schedule_bug+0x64/0x84)
[   27.245802] [<c014848c>] (__schedule_bug) from [<c084a2b0>] (__schedule+0x3fc/0x550)
[   27.253512] [<c084a2b0>] (__schedule) from [<c084a454>] (schedule+0x50/0xb4)
[   27.260533] [<c084a454>] (schedule) from [<c084ccb0>] (schedule_timeout+0x114/0x1e8)
[   27.268246] [<c084ccb0>] (schedule_timeout) from [<c016dd04>] (msleep+0x2c/0x38)
[   27.275612] [<c016dd04>] (msleep) from [<c057ebf8>] (XXX_ISR+0x34/0x8c)
[   27.282982] [<c057ebf8>] (XXX_ISR) from [<c015f928>] (__handle_irq_event_percpu+0x88/0x124)
[   27.292075] [<c015f928>] (__handle_irq_event_percpu) from [<c015f9e0>] (handle_irq_event_percpu+0x1c/0x58)
[   27.301693] [<c015f9e0>] (handle_irq_event_percpu) from [<c015fa54>] (handle_irq_event+0x38/0x5c)
[   27.310532] [<c015fa54>] (handle_irq_event) from [<c0162808>] (handle_edge_irq+0xe0/0x1a4)
[   27.318764] [<c0162808>] (handle_edge_irq) from [<c015ed64>] (generic_handle_irq+0x24/0x34)
[   27.327091] [<c015ed64>] (generic_handle_irq) from [<c0430ed8>] (exynos_irq_eint0_15+0x44/0x98)
[   27.335751] [<c0430ed8>] (exynos_irq_eint0_15) from [<c015ed64>] (generic_handle_irq+0x24/0x34)
[   27.344415] [<c015ed64>] (generic_handle_irq) from [<c015f20c>] (__handle_domain_irq+0x54/0xa8)
[   27.353080] [<c015f20c>] (__handle_domain_irq) from [<c010146c>] (vic_handle_irq+0x58/0x94)
[   27.361398] [<c010146c>] (vic_handle_irq) from [<c010ba4c>] (__irq_svc+0x6c/0xa8)
[   27.368847] Exception stack(0xc0d01f58 to 0xc0d01fa0)

总结一下：

硬件中断是超级宝贵的资源，想在中断里睡眠的话就得在大量的 critical section 中关闭中断才能避免 race condition，而关闭硬件中断将会大大地增加中断响应的延迟，降低系统的反应速度，这是操作系统的用户所无法接受的，
因此内核开发者采用的设计是在中断里不允许睡眠，并且 ISR 应尽快执行并返回以便系统里的进程继续运行。