Why cannot I sleep in the interrupt context?

Many people have asked this question. I have read the kernel code of Linux. The reason is as follows (of course, I cannot guarantee it is correct. If anyone can better understand it, please correct me)
1. process switching should not occur during interrupt processing, because in the interrupt context, the only interrupt that can interrupt the current handler is a higher priority interrupt, it will not be interrupted by the process (this is true for softirq and tasklet, so these bottom half cannot sleep). If it is dormant in the interrupt context, there is no way to wake it up, all wake_up_xxx is for a process, but in the context of interruption, there is no process concept, and there is no task_struct (this is the same for softirq and tasklet), so it is truly sleep, for example, if the block routine is called, the kernel will almost certainly die.
2. Schedule () saves the current process context (the value of the CPU register, the status of the process, and the content in the stack) when switching the process, so that the process can be resumed later. After the interrupt occurs, the kernel will first save the context of the currently interrupted process (restored after the interrupt processing program is called );
However, in the Interrupt Processing Program, the CPU register value must have changed (the most important program counter PC, stack sp, etc ), if schedule () is called because of sleep or blocking, the saved process context is not the current process context. therefore, schedule () cannot be called in the interrupt handler ().
3.2.4 The schedule () function in the kernel determines whether it is in the interrupt context when it comes in:
If (unlikely (in_interrupt ()))
Bug ();
Therefore, the result of forcibly calling schedule () is a kernel bug, but I don't know the implementation of Schedule () in kernel 2.6.18.
4. if handler is interrupted, it will use the kernel stack of the interrupted process, but it will not have any impact on it, because handler will completely clear the part of the stack it uses after it is used, restore the original appearance before the interruption.
5. When the context is interrupted, the kernel cannot be preemptible. Therefore, if it is sleep, the kernel must be suspended.

Certificate ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

First, the interrupt handling process is provided.

1. 1. enter the interrupt handler ---> 2. save the key context ----> 3. interrupt (STI command) ---> 4. enter the handler of the interrupt handler ---> 5. disconnection (CLI command) ----> 6. write The EOI register (indicating that the interrupt processing is completed) ----> 7. open interrupt.

Copy code

Hard interrupt:
For steps 1, 2, and 3, all interruptions are blocked during these steps. If you sleep at this time, the operating system will not receive any interruptions (including clock interruptions), and the system will be basically paralyzed (for example, the timer is not dependent on the clock cycle, etc ......)

Soft Interrupt:
Corresponding to Step 4 (of course, it should be accurate to the next point in Step 4. Let's talk about the insurance points first, so that we don't have to think about the truth again ). At this time, the key to sleep is context.
We all know that the operating system takes process scheduling as the unit. The process runs in the context of the process and uses the process descriptor as the managed data structure. The reason that a process can sleep is that the operating system can switch the context of different processes and perform scheduling operations. These operations are supported by the process descriptor.
The interrupt runs in the interrupt context. There is no so-called Interrupt Descriptor to describe it. It is not the scheduling unit of the operating system. Once sleep in the interrupt context, the context cannot be switched first (because there is no Interrupt Descriptor, the current context status cannot be saved). Secondly, no one will wake it up, because it is not the scheduling unit of the operating system.
In addition, the interruption occurs very frequently. During a sleep interruption, when other interruptions occur and sleep, the interruption Stack Overflow may easily cause the system to crash.

If the above conditions are met (that is, there is an Interrupt Descriptor and it becomes the scheduling unit of the scheduler, And the stack does not overflow, theoretically the sleep can be interrupted ), interruption can cause sleep, but may cause many problems. for example, if you sleep during clock interruption, the clock in the operating system will be messy, and the scheduler will lose the basis. For example, if you are in an IPI (processor interrupt, other CPUs are waiting for you to reply. If you are asleep, the other processors will not work. For example, if you are sleeping in a DMA interrupt, the above process is still waiting for the completion of I/O synchronization, and the performance is greatly reduced ...... There are also many examples. Therefore, interruption is an urgent task that requires immediate processing by the operating system. It does not mean that the system cannot sleep, but that it has no reason to sleep.

Certificate -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Interrupt generation is random. Assume that a kernel thread is interrupted for a certain time, and the task structure of this thread will be borrowed according to your solution, and the thread will sleep. If the priority of the interrupted thread is too low, it is difficult for the thread to execute again. In some cases, it may cause the system hang. If the priority of the interrupted thread is raised temporarily, a new wakeup mechanism should be designed to ensure that the high-priority thread that blocks the same lock is awakened first. At the same time, to temporarily improve the priority of the interrupted thread, You need to lock the acquisition process to add an algorithm to change the priority.