Why can't sleep functions be used in interrupt context?

From: http://blog.chinaunix.net/u1/49093/showart_1910189.html

Many people have asked this question. I have read the kernel code of Linux for the following reasons: (of course, I cannot guarantee that 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 thing that can interrupt the current handler is a higher-priority interrupt, which will not be interrupted by the process, if sleep in the interrupt context, there is no way to wake it up, because all wake_up_xxx is for a process, but there is no process concept in the interrupt context, there is no task_struct (this is the same for softirq and tasklet), so it is truly sleep. For example, if a 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. In kernel 2.4, the schedule () function itself checks 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. Interrupting handler 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 use, restore the original appearance before the interruption.

5. When the context is interrupted, the kernel cannot be preemptible. Therefore, the kernel must be suspended if it is sleep.

-------------------------------------------------------

 

Original post address: http://bbs.chinaunix.net/thread-2115820-1-1.html

 

Here we will reference the analysis that I think is relatively OK:

 

I like this discussion most. I am sorry to mention my opinion.
First, the interrupt handling process is provided.

 

1. 1. Access the interrupt processing program ---> 2. Save the key context ----> 3. Enable the interrupt (STI command) ---> 4. Access the Interrupt Processing Program
   Handler ---> 5. Disconnection (CLI command) ----> 6. Write The EOI register (indicating that the interrupt processing is complete) ----> 7. Enable 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.

For example
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, it can theoretically interrupt sleep ), interruption can cause sleep, but may cause many problems. example
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 interruption, other CPUs are in an endless loop, and you are sure
Sleep, And the other processors will not work. For example, if you sleep during a DMA interrupt, the above process is still waiting for I/O to complete, 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.

========================================================== ====================

 

Another article:

 

Http://blog.openrays.org/blog.php? Do = showone & tid = 455

 

Conclusion:

 

5. sleep problems during interrupt handling

In Linux, you cannot sleep during interrupt processing. There are many protection measures in this kernel. Once the kernel is detected, exceptions may occur.

When
When a process a is interrupted because of the interruption, the interrupt handler uses the kernel stack of A to save the context, because it is the cpu Of A, and
So the interruption should end as soon as possible. If do_irq is interrupted by the clock, the interrupt context is saved on the kernel stack of A. If scheduling occurs
Schedule enters switch_to and
In task _ struct-> thread_struct of A, the context of the interruption is saved.

If it is interrupted by a clock during sleep and schedule is used, if process a is selected and switch_to is used, the returned result is in the state of the original sleep interrupted, aside from disrupting the operation of process A, the question here is: how to wake it up ??

In addition, the interruption that shares the interrupt number with the interrupt will also be affected.

 

========================================================== ====================

 

Another article is well analyzed:

 

Http://blog.csdn.net/maray/article/details/5770889

 

Conclusion:

Linux is a process-based scheduling unit. The Scheduler only sees the process Kernel stack, but does not see the interrupt stack. In the standalone interrupt stack mode, if the Linux kernel is scheduled in the interrupt path (technically speaking, sleep and scheduling are the same), Linux cannot find the "Way Home ", the unexecuted Interrupt Processing code will no longer be available for execution.