一、基本概念
中断分为同步中断和异步中断。同步中断是由CPU控制单元产生的，“同步”是指只有在一条指令执行完毕后，CPU才会发出中断，而不是发生在代码指令执行期间，比如系统调用。而异步中断是由其他硬件设备依照CPU时钟信号产生的，即意味着中断能够在指令之间发生，例如键盘中断。
按照Intel的微处理器手册，同步中断和异步中断也分别称为异常（或者软件中断）和中断。中断大家都比较熟悉，是由硬件设备产生的。异常的产生源有两种：一种是由程序的错误产生的，内核通过发送一个Unix程序员都熟悉的信号来处理异常；第二种时内核必须处理的异常条件产生的，此时内核执行恢复异常需要的所有步骤，例如缺页，或对内核服务的一个请求（系统调用，通过一条int指令）。有一个知识点值得了解：内核态能够触发的唯一异常就是缺页异常，其他的都是用户态触发的。
二、硬中断、软中断、异常之间的抢占关系
硬中断可以被另一个优先级比自己高的硬中断“中断”，不能被同级（同一种硬中断）或低级的硬中断“中断”，更不能被软中断“中断”。
软中断可以被硬中断“中断”，但是不会被另一个软中断“中断”。在一个CPU上，软中断总是串行执行。所以在单处理器上，对软中断的数据结构进行访问不需要加任何同步原语。
（关于这一点，我对《深入理解linux内核》第三版P223页中保护可延迟函数所访问的数据结构有疑问，书上说保护可延迟函数（软中断）所访问的数据结构应采取的措施：对于单处理器的情况，在单处理器上不存在竞争条件，这是因为可延迟函数（软中断）的执行总是在一个CPU上串行执行--也就是说，一个可延迟函数不会被另一个可延迟函数中断。因此，根本不需要同步原语。我认为：一个软中断虽然不会被另一个软中断“中断”，但是可能被硬中断“中断”，而硬中断最后还是要执行到软中断，因此还是会形成对资源的临界区访问。我觉得在保护软中断时，应该关闭本地软中断，比如用local_bh_disable）
还没写完这篇博客，就知道我在这个问题上错了。附上在Linux 内核开发中文邮件列表上某位仁兄提供的解答。
开始处理软中断的情况主要是
1、中断退出执行的irq_exit
2、内核线程ksoftirqd
3、local_bh_enable
而
asmlinkage void do_softirq(void)
{
unsigned long flags;
struct thread_info *curctx;
union irq_ctx *irqctx;
u32 *isp;
if (in_interrupt())
return;
....
}
可以看到，in_interrupt 判断，当前若是从硬件中断退出后执行的irq_exit进入的do_softirq，则立即返回，可以避免你说的情况
本文最后还将附上一篇软中断源码的分析，很详细地说明了这个问题。
硬中断和软中断都可以抢占（或者称为中断）异常（最典型的是系统调用），但是异常不能抢占硬中断和软中断。
硬中断和软中断（只要是中断上下文）执行的时候都不允许内核抢占，换句话说，中断上下文中永远不允许进程切换。（个人理解，由于中断处理程序都需要较快地完成，而且中断处理程序可以嵌套，因此中断处理程序必须不能阻塞，否则性能就非常不能保证了。）
三、用户抢占和内核抢占
抢占分两种情况：用户抢占和内核抢占，其中内核抢占在Linux2.5.4版本发布时被并入内核的，通SMP一样作为内核的一项标准可选配置。
1、用户抢占：内核即将返回用户空间的时候，如果need resched标志被设置，会导致schedule()被调用，此时就会发生用户抢占。在内核返回用户空间的时候，它知道自己是安全的。所以，内核无论是在从中断处理程序还是在系统调用后返回，都会检查need resched标志。如果它被设置了，那么，内核会选择一个其他(更合适的)进程投入运行。在内核抢占还没有出现的时候，内核所有的抢占情况都是用户抢占。
2、内核抢占：内核抢占是指，一个在内核态运行的进程，可能在执行内核函数期间被另一个进程取代。不是在内核的任何一个地方都可以发生内核抢占的。
内核不能被抢占的情况如下：
1）内核正进行中断处理。在Linux内核中进程不能抢占中断(中断只能被其他中断中止、抢占，进程不能中止、抢占中断)，在中断例程中不允许进行进程调度。进程调度函数schedule()会对此作出判断，如果是在中断中调用，会打印出错信息。
2）内核正在进行中断上下文的Bottom Half(中断的底半部)处理。硬件中断返回前会执行软中断，此时仍然处于中断上下文中。
3）内核的代码段正持有spinlock自旋锁、writelock/readlock读写锁等锁，处干这些锁的保护状态中。内核中的这些锁是为了在SMP系统中短时间内保证不同CPU上运行的进程并发执行的正确性。当持有这些锁时，内核不应该被抢占。
4）内核正在执行调度程序Scheduler。抢占的原因就是为了进行新的调度，没有理由将调度程序抢占掉再运行调度程序。
5）内核正在对每个CPU“私有”的数据结构操作(Per-CPU date structures)。在SMP中，对于per-CPU数据结构未用spinlocks保护，因为这些数据结构隐含地被保护了(不同的CPU有不一样的per-CPU数据，其他CPU上运行的进程不会用到另一个CPU的per-CPU数据)。但是如果允许抢占，但一个进程被抢占后重新调度，有可能调度到其他的CPU上去，这时定义的Per-CPU变量就会有问题，这时应禁抢占。
除了上述情况，在内核的任何地方都可能发生内核抢占，内核抢占发生的时机一般在：
1）当从中断处理程序正在执行，且返回内核空间之前。
2）当内核代码再一次具有可抢占性的时候，如解锁（spin_unlock_bh）及使能软中断(local_bh_enable)等。
3）如果内核中的任务显式的调用schedule()。
4）如果内核中的任务阻塞(这同样也会导致调用schedule())。
内核抢占主要是为实时系统来设计的，但也不是在所有情况下都是最优的，因为抢占也需要调度和同步开销，在某些情况下甚至要关闭内核抢占。以下是一篇关于开启和关闭内核抢占性能测试的文章。http://www.ibm.com/developerworks/cn/linux/l-nptl/index.html
四、怎么对内核临界区进行保护
在进程内核数据结构的互斥同步访问时，我们最常用的办法是：信号量（睡眠等待），自旋锁（自旋等待），中断禁止和软中断禁止。往往需要几种方法配合使用才能达到我们想要的结果。
1、保护异常（最典型的是系统调用）所访问的数据结构
此时最常选用的是信号量，因为信号量原语允许进程睡眠到资源变为可用，对大部分系统调用而言，这是所期望的行为。信号量的工作方式在单处理器系统和多处理器系统上完全相同。只有在访问每CPU变量的情况下，必须显式地禁用内核抢占，其他情况下内核抢占不会出现问题。
2、保护中断所访问的数据结构
1）单处理器情况下：假如数据结构只被这一种中断访问，则完全可以不加同步原语，因为中断不能被同一种中断“中断”；假如数据结构被多个中断处理程序访问，则必须通过禁用本地中断来保护临界区。
2）多处理器情况下：除了必须禁用本地中断，还必须使用自旋锁来避免来自其他CPU的干扰。可以使用如spin_lock_irq()来完成这两件事情。
3、保护可延迟函数（软中断和tasklet）所访问的数据结构
1）单处理器情况下：在单处理器系统上不存在竞争条件，因为可延迟函数的执行在一个CPU上是串行的，一个可延迟函数不会被另一个可延迟函数所中断。因此无需同步原语。
2）多处理器情况下：需要自旋锁来加以保护。由于软中断和tasklet并发程度不同，加锁情况也不同。同一软中断可以在不同CPU上运行，因此无论一个或多个软中断，都必须用如spin_lock加以保护。同一tasklet不能在不同CPU上运行，因此无需加锁；不同tasklet可以在不同CPU上运行，因此也需要如spin_lock的锁加以保护。
4、保护由异常和中断访问的数据结构
单处理器情况下：
1）对中断而言：中断不能被异常“中断”，无需考虑异常的干扰。第1条一样，如果此数据结构只被一种中断访问，则可不加同步原语；否则要禁用本地中断。
2）对异常而言：异常的优先级低，如需访问共享数据结构，必须先禁用本地中断。
多处理器情况下：
1）对中断而言：除了单处理器考虑的情况外，还必须用自旋锁排除其他CPU的干扰。
2）对异常而言：除了单处理器考虑的情况外，还必须用自旋锁排除其他CPU的干扰。
5、保护由异常和可延迟函数访问的数据结构
单处理器情况下：
1）对可延迟函数而言：可延迟函数不能被异常“中断”，无需考虑异常的干扰。在每个CPU上可延迟函数串行执行，不存在竞争条件，因此不用同步原语。
2）对异常而言：异常的优先级低，如需访问共享数据结构，必须先禁用本地软中断。
多处理器情况下：
1）对中断而言：除了单处理器考虑的情况外，还必须用自旋锁排除其他CPU的干扰。
2）对异常而言：除了单处理器考虑的情况外，还必须用自旋锁排除其他CPU的干扰。
6、保护由中断和可延迟函数访问的数据机构
单处理器情况下：
1）对中断而言：中断不能被可延迟函数“中断”，无需考虑可延迟函数的干扰。第1条一样，如果此数据结构只被一种中断访问，则可不加同步原语；否则要禁用本地中断。
2）对可延迟函数而言：可延迟函数的优先级低，如需访问共享数据结构，必须先禁用本地中断。
多处理器情况下：
1）对中断而言：除了单处理器上考虑的外，还必须用自旋锁排除其他CPU的干扰。
2）对可延迟函数而言：除了单处理器上考虑的外，还必须用自旋锁排除其他CPU的干扰。
7、保护由异常、中断和可延迟函数访问的数据结构
单处理器情况下：
1）对中断而言：优先级最高，无需考虑其他两种的影响。第1条一样，如果此数据结构只被一种中断访问，则可不加同步原语；否则要禁用本地中断。
2）对可延迟函数而言：可延迟函数的优先级低，如需访问共享数据结构，必须先禁用本地中断。
3）对异常而言：可延迟函数的优先级低，如需访问共享数据结构，必须先禁用本地中断。禁用了本地中断，也就相当于禁用了本地软中断。
多处理器情况下：
1）对中断而言：除了单处理器上考虑的外，还必须用自旋锁排除其他CPU的干扰。
2）对可延迟函数而言：除了单处理器上考虑的外，还必须用自旋锁排除其他CPU的干扰。
3）对异常而言：除了单处理器上考虑的外，还必须用自旋锁排除其他CPU的干扰。
五、软中断源码分析
之所以说软中断的执行时是串行的，是因为在软中断执行时，对于从硬中断进来的即将要执行的新的软中断会采取屏蔽措施，不让他们立即运行，而是保存起来，延迟一会，等自身的软中断执行完毕后，再执行那些保存起来的软中断，从而达到串行的目的。
1 // 2 // do_IRQ 函数执行完硬件 ISR 后退出时调用此函数。 3 // 4 void irq_exit(void) 5 { 6 account_system_vtime(current); 7 trace_hardirq_exit(); 8 sub_preempt_count(IRQ_EXIT_OFFSET); 9 // 10 // 判断当前是否有硬件中断嵌套，并且是否有软中断在 11 // pending 状态，注意：这里只有两个条件同时满足 12 // 时，才有可能调用 do_softirq() 进入软中断。也就是 13 // 说确认当前所有硬件中断处理完成，且有硬件中断安装了 14 // 软中断处理时理时才会进入。 15 // 16 if (!in_interrupt() && local_softirq_pending()) 17 // 18 // 其实这里就是调用 do_softirq() 执行 19 // 20 invoke_softirq(); 21 preempt_enable_no_resched(); 22 } 23 #ifndef __ARCH_HAS_DO_SOFTIRQ 24 asmlinkage void do_softirq(void) 25 { 26 __u32 pending; 27 unsigned long flags; 28 // 29 // 这个函数判断，如果当前有硬件中断嵌套，或 30 // 有软中断正在执行时候，则马上返回。在这个 31 // 入口判断主要是为了和 ksoftirqd 互斥。 32 // 33 if (in_interrupt()) 34 return; 35 // 36 // 关中断执行以下代码 37 // 38 local_irq_save(flags); 39 // 40 // 判断是否有 pending 的软中断需要处理。 41 // 42 pending = local_softirq_pending(); 43 // 44 // 如果有则调用 __do_softirq() 进行实际处理 45 // 46 if (pending) 47 __do_softirq(); 48 // 49 // 开中断继续执行 50 // 51 local_irq_restore(flags); 52 } 53 // 54 // 最大软中断调用次数为 10 次。 55 // 56 #define MAX_SOFTIRQ_RESTART 10 57 asmlinkage void __do_softirq(void) 58 { 59 // 60 // 软件中断处理结构，此结构中包括了 ISR 中 61 // 注册的回调函数。 62 // 63 struct softirq_action *h; 64 __u32 pending; 65 int max_restart = MAX_SOFTIRQ_RESTART; 66 int cpu; 67 // 68 // 得到当前所有 pending 的软中断。 69 // 70 pending = local_softirq_pending(); 71 account_system_vtime(current); 72 // 73 // 执行到这里要屏蔽其他软中断，这里也就证实了 74 // 每个 CPU 上同时运行的软中断只能有一个。 75 // 76 __local_bh_disable((unsigned long)__builtin_return_address(0)); 77 trace_softirq_enter(); 78 // 79 // 针对 SMP 得到当前正在处理的 CPU 80 // 81 cpu = smp_processor_id(); 82 // 83 // 循环标志 84 // 85 restart: 86 // 87 // 每次循环在允许硬件 ISR 强占前，首先重置软中断 88 // 的标志位。 89 // 90 /* Reset the pending bitmask before enabling irqs */ 91 set_softirq_pending(0); 92 // 93 // 到这里才开中断运行，注意：以前运行状态一直是关中断 94 // 运行，这时当前处理软中断才可能被硬件中断抢占。也就 95 // 是说在进入软中断时不是一开始就会被硬件中断抢占。只有 96 // 在这里以后的代码才可能被硬件中断抢占。 97 // 98 local_irq_enable(); 99 // 100 // 这里要注意，以下代码运行时能被硬件中断抢占，但 101 // 这个硬件 ISR 执行完成后，他的所注册的软中断无法马上运行， 102 // 别忘了，目前虽是开硬件中断执行，但前面的 __local_bh_disable() 103 // 函数屏蔽了软中断。所以这种环境下只能被硬件中断抢占，但这 104 // 个硬中断注册的软中断回调函数无法运行。要问为什么，那是因为 105 // __local_bh_disable() 函数设置了一个标志当作互斥量，而这个 106 // 标志正是上面的 irq_exit() 和 do_softirq() 函数中的 107 // in_interrupt() 函数判断的条件之一，也就是说 in_interrupt() 108 // 函数不仅检测硬中断而且还判断了软中断。所以在这个环境下触发 109 // 硬中断时注册的软中断，根本无法重新进入到这个函数中来，只能 110 // 是做一个标志，等待下面的重复循环（最大 MAX_SOFTIRQ_RESTART） 111 // 才可能处理到这个时候触发的硬件中断所注册的软中断。 112 // 113 // 114 // 得到软中断向量表。 115 // 116 h = softirq_vec; 117 // 118 // 循环处理所有 softirq 软中断注册函数。 119 // 120 do { 121 // 122 // 如果对应的软中断设置 pending 标志则表明 123 // 需要进一步处理他所注册的函数。 124 // 125 if (pending & 1) { 126 // 127 // 在这里执行了这个软中断所注册的回调函数。 128 // 129 h->action(h); 130 rcu_bh_qsctr_inc(cpu); 131 } 132 // 133 // 继续找，直到把软中断向量表中所有 pending 的软 134 // 中断处理完成。 135 // 136 h++; 137 // 138 // 从代码里能看出按位操作，表明一次循环只 139 // 处理 32 个软中断的回调函数。 140 // 141 pending >>= 1; 142 } while (pending); 143 // 144 // 关中断执行以下代码。注意：这里又关中断了，下面的 145 // 代码执行过程中硬件中断无法抢占。 146 // 147 local_irq_disable(); 148 // 149 // 前面提到过，在刚才开硬件中断执行环境时只能被硬件中断 150 // 抢占，在这个时候是无法处理软中断的，因为刚才开中 151 // 断执行过程中可能多次被硬件中断抢占，每抢占一次就有可 152 // 能注册一个软中断，所以要再重新取一次所有的软中断。 153 // 以便下面的代码进行处理后跳回到 restart 处重复执行。 154 // 155 pending = local_softirq_pending(); 156 // 157 // 如果在上面的开中断执行环境中触发了硬件中断，且每个都 158 // 注册了一个软中断的话，这个软中断会设置 pending 位， 159 // 但在当前一直屏蔽软中断的环境下无法得到执行，前面提 160 // 到过，因为 irq_exit() 和 do_softirq() 根本无法进入到 161 // 这个处理过程中来。这个在上面周详的记录过了。那么在 162 // 这里又有了一个执行的机会。注意：虽然当前环境一直是 163 // 处于屏蔽软中断执行的环境中，但在这里又给出了一个执行 164 // 刚才在开中断环境过程中触发硬件中断时所注册的软中断的 165 // 机会，其实只要理解了软中断机制就会知道，无非是在一些特 166 // 定环境下调用 ISR 注册到软中断向量表里的函数而已。 167 // 168 // 169 // 如果刚才触发的硬件中断注册了软中断，并且重复执行次数 170 // 没有到 10 次的话，那么则跳转到 restart 标志处重复以上 171 // 所介绍的所有步骤：设置软中断标志位，重新开中断执行... 172 // 注意：这里是要两个条件都满足的情况下才可能重复以上步骤。 173 // 174 if (pending && --max_restart) 175 goto restart; 176 // 177 // 如果以上步骤重复了 10 次后更有 pending 的软中断的话， 178 // 那么系统在一定时间内可能达到了一个峰值，为了平衡这点。 179 // 系统专门建立了一个 ksoftirqd 线程来处理，这样避免在一 180 // 定时间内负荷太大。这个 ksoftirqd 线程本身是个大循环， 181 // 在某些条件下为了不负载过重，他是能被其他进程抢占的， 182 // 但注意，他是显示的调用了 preempt_xxx() 和 schedule() 183 // 才会被抢占和转换的。这么做的原因是因为在他一旦调用 184 // local_softirq_pending() 函数检测到有 pending 的软中断 185 // 需要处理的时候，则会显示的调用 do_softirq() 来处理软中 186 // 断。也就是说，下面代码唤醒的 ksoftirqd 线程有可能会回 187 // 到这个函数当中来，尤其是在系统需要响应非常多软中断的情况 188 // 下，他的调用入口是 do_softirq()，这也就是为什么在 do_softirq() 189 // 的入口处也会用 in_interrupt() 函数来判断是否有软中断 190 // 正在处理的原因了，目的还是为了防止重入。ksoftirqd 实现 191 // 看下面对 ksoftirqd() 函数的分析。 192 // 193 if (pending) 194 // 195 // 此函数实际是调用 wake_up_process() 来唤醒 ksoftirqd 196 // 197 wakeup_softirqd(); 198 trace_softirq_exit(); 199 account_system_vtime(current); 200 // 201 // 到最后才开软中断执行环境，允许软中断执行。注意：这里 202 // 使用的不是 local_bh_enable()，不会再次触发 do_softirq() 203 // 的调用。 204 // 205 _local_bh_enable(); 206 } 207 static int ksoftirqd(void * __bind_cpu) 208 { 209 // 210 // 显示调用此函数设置当前进程的静态优先级。当然， 211 // 这个优先级会随调度器策略而变化。 212 // 213 set_user_nice(current, 19); 214 // 215 // 设置当前进程不允许被挂启 216 // 217 current->flags |= PF_NOFREEZE; 218 // 219 // 设置当前进程状态为可中断的状态，这种睡眠状 220 // 态可响应信号处理等。 221 // 222 set_current_state(TASK_INTERRUPTIBLE); 223 // 224 // 下面是个大循环，循环判断当前进程是否会停止， 225 // 不会则继续判断当前是否有 pending 的软中断需 226 // 要处理。 227 // 228 while (!kthread_should_stop()) { 229 // 230 // 如果能进行处理，那么在此处理期间内禁止 231 // 当前进程被抢占。 232 // 233 preempt_disable(); 234 // 235 // 首先判断系统当前没有需要处理的 pending 状态的 236 // 软中断 237 // 238 if (!local_softirq_pending()) { 239 // 240 // 没有的话在主动放弃 CPU 前先要允许抢占，因为 241 // 一直是在不允许抢占状态下执行的代码。 242 // 243 preempt_enable_no_resched(); 244 // 245 // 显示调用此函数主动放弃 CPU 将当前进程放入睡眠队列， 246 // 并转换新的进程执行（调度器相关不记录在此） 247 // 248 schedule(); 249 // 250 // 注意：如果当前显示调用 schedule() 函数主动转换的进 251 // 程再次被调度执行的话，那么将从调用这个函数的下一条 252 // 语句开始执行。也就是说，在这里当前进程再次被执行的 253 // 话，将会执行下面的 preempt_disable() 函数。 254 // 255 // 256 // 当进程再度被调度时，在以下处理期间内禁止当前进程 257 // 被抢占。 258 // 259 preempt_disable(); 260 } 261 // 262 // 设置当前进程为运行状态。注意：已设置了当前进程不可抢占 263 // 在进入循环后，以上两个分支不论走哪个都会执行到这里。一是 264 // 进入循环时就有 pending 的软中断需要执行时。二是进入循环时 265 // 没有 pending 的软中断，当前进程再次被调度获得 CPU 时继续 266 // 执行时。 267 // 268 __set_current_state(TASK_RUNNING); 269 // 270 // 循环判断是否有 pending 的软中断，如果有则调用 do_softirq() 271 // 来做具体处理。注意：这里又是个 do_softirq() 的入口点， 272 // 那么在 __do_softirq() 当中循环处理 10 次软中断的回调函数 273 // 后，如果更有 pending 的话，会又调用到这里。那么在这里则 274 // 又会有可能去调用 __do_softirq() 来处理软中断回调函数。在前 275 // 面介绍 __do_softirq() 时已提到过，处理 10 次还处理不完的 276 // 话说明系统正处于繁忙状态。根据以上分析，我们能试想如果在 277 // 系统非常繁忙时，这个进程将会和 do_softirq() 相互交替执行， 278 // 这时此进程占用 CPU 应该会非常高，虽然下面的 cond_resched() 279 // 函数做了一些处理，他在处理完一轮软中断后当前处理进程可能会 280 // 因被调度而减少 CPU 负荷，不过在非常繁忙时这个进程仍然有可 281 // 能大量占用 CPU。 282 // 283 while (local_softirq_pending()) { 284 /* Preempt disable stops cpu going offline. 285 If already offline, we’ll be on wrong CPU: 286 don’t process */ 287 if (cpu_is_offline((long)__bind_cpu)) 288 // 289 // 如果当前被关联的 CPU 无法继续处理则跳转 290 // 到 wait_to_die 标记出，等待结束并退出。 291 // 292 goto wait_to_die; 293 // 294 // 执行 do_softirq() 来处理具体的软中断回调函数。注 295 // 意：如果此时有一个正在处理的软中断的话，则会马上 296 // 返回，还记得前面介绍的 in_interrupt() 函数么。 297 // 298 do_softirq(); 299 // 300 // 允许当前进程被抢占。 301 // 302 preempt_enable_no_resched(); 303 304 // 305 // 这个函数有可能间接的调用 schedule() 来转换当前 306 // 进程，而且上面已允许当前进程可被抢占。也就是 307 // 说在处理完一轮软中断回调函数时，有可能会转换到 308 // 其他进程。我认为这样做的目的一是为了在某些负载 309 // 超标的情况下不至于让这个进程长时间大量的占用 CPU， 310 // 二是让在有非常多软中断需要处理时不至于让其他进程 311 // 得不到响应。 312 // 313 cond_resched(); 314 // 315 // 禁止当前进程被抢占。 316 // 317 preempt_disable(); 318 // 319 // 处理完所有软中断了吗？没有的话继续循环以上步骤 320 // 321 } 322 // 323 // 待一切都处理完成后，允许当前进程被抢占，并设置 324 // 当前进程状态为可中断状态，继续循环以上所有过程。 325 // 326 preempt_enable(); 327 set_current_state(TASK_INTERRUPTIBLE); 328 } 329 330 // 331 // 如果将会停止则设置当前进程为运行状态后直接返回。 332 // 调度器会根据优先级来使当前进程运行。 333 // 334 __set_current_state(TASK_RUNNING); 335 return 0; 336 // 337 // 一直等待到当前进程被停止 338 // 339 wait_to_die: 340 // 341 // 允许当前进程被抢占。 342 // 343 preempt_enable(); 344 /* Wait for kthread_stop */ 345 // 346 // 设置当前进程状态为可中断的状态，这种睡眠状 347 // 态可响应信号处理等。 348 // 349 set_current_state(TASK_INTERRUPTIBLE); 350 // 351 // 判断当前进程是否会被停止，如果不是的话 352 // 则设置进程状态为可中断状态并放弃当前 CPU 353 // 主动转换。也就是说这里将一直等待当前进程 354 // 将被停止时候才结束。 355 // 356 while (!kthread_should_stop()) { 357 schedule(); 358 set_current_state(TASK_INTERRUPTIBLE); 359 } 360 // 361 // 如果将会停止则设置当前进程为运行状态后直接返回。 362 // 调度器会根据优先级来使当前进程运行。 363 // 364 __set_current_state(TASK_RUNNING); 365 return 0; 366 }