Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why kernel code/thread executing in interrupt context cannot sleep?

Tags:

linux-kernel

I am reading following article by Robert Love

http://www.linuxjournal.com/article/6916

that says

"...Let's discuss the fact that work queues run in process context. This is in contrast to the other bottom-half mechanisms, which all run in interrupt context. Code running in interrupt context is unable to sleep, or block, because interrupt context does not have a backing process with which to reschedule. Therefore, because interrupt handlers are not associated with a process, there is nothing for the scheduler to put to sleep and, more importantly, nothing for the scheduler to wake up..."

I don't get it. AFAIK, scheduler in the kernel is O(1), that is implemented through the bitmap. So what stops the scehduler from putting interrupt context to sleep and taking next schedulable process and passing it the control?

like image 240
Methos Avatar asked Jun 27 '09 20:06

Methos


People also ask

Why can t interrupt handlers sleep?

You can't sleep in interrupt handlers in Linux because they are not backed by a thread of execution. In other words, they aren't schedulable entities. Most systems break interrupt processing into two halves, commonly called a top half and a bottom half.

Is it possible for an interrupt handler code triggered by a hardware interrupt to sleep while waiting for another event if so explain how if not explain why not?

(1) “NO”: Strictly speaking, an interrupt handler must not sleep while waiting for another event, since it doesn't have a thread-control block (context) to put onto a wait queue and is operating with interrupts disabled.

Can interrupts occur in kernel mode?

The interrupt handling code (part of OS) is executed in kernel mode. The interrupt vector can be modified only in kernel mode.

Does the kernel handle interrupts?

Interrupt handling in Linux. In Linux the interrupt handling is done in three phases: critical, immediate and deferred. In the first phase the kernel will run the generic interrupt handler that determines the interrupt number, the interrupt handler for this particular interrupt and the interrupt controller.


1 Answers

So what stops the scehduler from putting interrupt context to sleep and taking next schedulable process and passing it the control?

The problem is that the interrupt context is not a process, and therefore cannot be put to sleep.

When an interrupt occurs, the processor saves the registers onto the stack and jumps to the start of the interrupt service routine. This means that when the interrupt handler is running, it is running in the context of the process that was executing when the interrupt occurred. The interrupt is executing on that process's stack, and when the interrupt handler completes, that process will resume executing.

If you tried to sleep or block inside an interrupt handler, you would wind up not only stopping the interrupt handler, but also the process it interrupted. This could be dangerous, as the interrupt handler has no way of knowing what the interrupted process was doing, or even if it is safe for that process to be suspended.

A simple scenario where things could go wrong would be a deadlock between the interrupt handler and the process it interrupts.

  1. Process1 enters kernel mode.
  2. Process1 acquires LockA.
  3. Interrupt occurs.
  4. ISR starts executing using Process1's stack.
  5. ISR tries to acquire LockA.
  6. ISR calls sleep to wait for LockA to be released.

At this point, you have a deadlock. Process1 can't resume execution until the ISR is done with its stack. But the ISR is blocked waiting for Process1 to release LockA.

like image 58
Keith Smith Avatar answered Sep 26 '22 00:09

Keith Smith