版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/dzw19911024/article/details/79576592
1、 中断处理的时候,不应该发生进程切换，因为在中断context中，唯一能打断当前中断handler的只有更高优先级的中断，它不会被进程打断，如果在 中断context中休眠，则没有办法唤醒它，因为所有的wake_up_xxx都是针对某个进程而言的，而在中断context中，没有进程的概念，没 有一个task_struct（这点对于softirq和tasklet一样），因此真的休眠了，比如调用了会导致block的例程，内核几乎肯定会死
2、schedule()在切换进程时，保存当前的进程上下文（CPU寄存器的值、进程的状态以及堆栈中的内容），以便以后恢复此进程运行。中断发生后，内核会先保存当前被中断的进程上下文（在调用中断处理程序后恢复）；
但在中断处理程序里，CPU寄存器的值肯定已经变化了吧（最重要的程序计数器PC、堆栈SP等），如果此时因为睡眠或阻塞操作调用了schedule()，则保存的进程上下文就不是当前的进程context了.所以不可以在中断处理程序中调用schedule()。
3、中断处理程序是带便进程执行的，它所代表的进程必须总处理TASK_RUNNING状态。当一个中断处理程序正在运行时，他所代表的IRQ线上发出的信号就会暂时被忽略
4、同样也是为了实现中断嵌套进行所付出的代价，如果要保证可以中断嵌套，就中断处理程序必须永不阻塞。