上下文这个词会让人想到进程的CPU寄存器状态，但好像进入进程上下文（异常处理系统调用）和进入中断上下文（中断处理），内核所做的工作没有太大区别。所以，这两个上下文的主要区别，我认为在于是否与进程相关。
运行于进程上下文的内核代码是可抢占的，但中断上下文则会一直运行至结束，不会被抢占。因此，内核会限制中断上下文的工作，不允许其执行如下操作：
(1) 进入睡眠状态或主动放弃CPU;
由于中断上下文不属于任何进程，它与current没有任何关系（尽管此时current指向被中断的进程），所以中断上下文一旦睡眠或者放弃CPU，将无法被唤醒。所以也叫原子上下文（atomic context）。
(2) 占用互斥体;
为了保护中断句柄临界区资源，不能使用mutexes。如果获得不到信号量，代码就会睡眠，会产生和上面相同的情况，如果必须使用锁，则使用spinlock。
(3) 执行耗时的任务;
中断处理应该尽可能快，因为内核要响应大量服务和请求，中断上下文占用CPU时间太长会严重影响系统功能。在中断处理例程中执行耗时任务时，应该交由中断处理例程底半部来处理。
(4) 访问用户空间虚拟内存。
因为中断上下文是和特定进程无关的，它是内核代表硬件运行在内核空间，所以在中断上下文无法访问用户空间的虚拟地址
(5) 中断处理例程不应该设置成reentrant（可被并行或递归调用的例程）。
因为中断发生时，preempt和irq都被disable，直到中断返回。所以中断上下文和进程上下文不一样，中断处理例程的不同实例，是不允许在SMP上并发运行的。
(6)中断处理例程可以被更高级别的IRQ中断。（不能嵌套中断）使用软中断，上部分关中断，也就是禁止嵌套，下半部分使用软中断
如果想禁止这种中断，可以将中断处理例程定义成快速处理例程，相当于告诉CPU，该例程运行时，禁止本地CPU上所有中断请求。这直接导致的结果是，由于其他中断被延迟响应，系统性能下降。
软中断是一种延时机制，代码执行的优先级比进程要高，比硬中断要低。相比于硬件中断，软中段是在开中断的环境中执行的（长时间关中断对系统的开销太大）， 代码是执行在中断/线程上下文的，是不能睡眠的，虽然每个cpu都有一个对应的ksoftirqd/n线程来执行软中断，但是do_softirq这个函数也还会在中断退出时调用到，因此不能睡眠(中断上下文不能睡眠的原因是由于调度系统是以进程为基本单位的，调度时会把当前进程的上下文保存在task_struct这个数据结构中，当进程被调度重新执行时会找到执行的断点，但是中断上下文是没有特定task_struct结构体的，当然现在有所谓的线程话中断，可以满足在中断处理函数执行阻塞操作，但是实时性可能会有问题。还有就是中断代表当前进程执行的概念，个人感觉有点扯淡，毕竟整个内核空间是由所有进程共享的，不存在代表的概念)
