Why software interrupts can sleep while it is not allowed in hardware interrupts?

Question

Why we can sleep in software interrupt case while it is not allowed in case of hardware interrupt? e.g. System calls can sleep while ISR cannot sleep.

Answer 1

When you enter in the kernel code through a process (i.e., a syscall) the kernel is said to be in process context. This means that the kernel is executed on behalf of a process. The execution of the kernel is synchronous with the user-level, and therefore it is possible to access user-level. It is also possible to call sleeping functions, because the scheduler is capable of schedule a new process.

When you enter in the kernel from a hardware source (i.e., an interrupt), then the kernel is said to be in interrupt context. The execution of the kernel is asynchronous with respect to the user-level, and you cannot do any ssumption of what is being executed at user-level. For example, some resources may be in some unconsistent state. For this reason, the code cannot block because the scheduler cannot schedule a new process.

This difference is well explained in Rubini's book Linux Device Drivers, 3rd edition which is freely available on the web.

Answer 2

1. Normally, ISRs run with interrupt disabled, so if sleeped in ISR we have no chance to wake up.
2. Interrupt handler uses interrupted process's kernel stack. If we switched to other process in ISR, the kernel stack will be changed to other process's.