Linux ARM架构IRQ抢占机制：中断退出路径调度返回逻辑疑问

你的疑问核心拆解与解答 #

首先要明确一个关键前提：在进入__irq_svc时，svc_entry irq_handler这个宏已经完整保存了被中断任务（taskA）的全部上下文——包括所有通用寄存器、进入异常前的程序计数器（PC）、栈指针（SP）等，这些信息都存在taskA专属的内核栈上。这是理解后续流程的基础。

1. 抢占调度时taskA的上下文是怎么保存的？ #

当代码走到blne svc_preempt时，svc_preempt内部会调用调度器核心函数schedule()。在schedule()执行上下文切换时，会把taskA当前的执行状态（包括此时的PC值——也就是svc_preempt执行完成后的返回地址，也就是svc_exit r5, irq = 1这一行的指令地址）完整保存到taskA的task_struct关联的thread_info结构中。

简单说：taskA被抢占时，它的执行进度停在了“刚调用完svc_preempt，准备执行svc_exit”的节点，这个节点的所有状态都被妥善保存了，并没有丢失。

2. 下次调度回taskA时，会从哪里继续执行？ #

当调度器再次选中taskA运行时，会把之前保存的上下文完整恢复：CPU的PC会被设置为之前保存的返回地址，也就是直接回到__irq_svc中的svc_exit指令处，继续执行中断退出的收尾工作。

svc_exit会完成这些操作：

• 恢复之前svc_entry保存的taskA的寄存器
• 处理异常返回的权限切换
• 最终回到taskA被IRQ中断前的执行点（用户态或内核态）

3. 为什么不用担心其他IRQ覆盖svc_exit的上下文？ #

Linux中每个任务都有独立的内核栈，taskA的内核栈和taskB的内核栈是完全隔离的。当taskB运行时触发新的IRQ，只会使用taskB自己的内核栈来保存上下文，完全不会触碰taskA的内核栈。所以taskA保存的“等待执行svc_exit”的上下文是安全的，不会被其他任务的IRQ操作覆盖。

再结合源码梳理完整路径 #

__irq_svc:
    svc_entry irq_handler  // 保存taskA的全部上下文到它的内核栈
#ifdef CONFIG_PREEMPTION
    ldr r8, [tsk, #TI_PREEMPT]    // 检查抢占计数
    ldr r0, [tsk, #TI_FLAGS]        // 检查调度标志
    teq r8, #0                    // 抢占计数为0才允许抢占
    movne r0, #0                    // 不允许抢占则清空标志
    tst r0, #_TIF_NEED_RESCHED
    blne svc_preempt  // 触发抢占，调用schedule()切换到taskB
#endif
    svc_exit r5, irq = 1  // taskA被调度回来时，从这里继续执行，完成中断退出

总结一下：taskA被IRQ抢占切换到taskB后，下次调度回taskA时，会从svc_preempt返回后的svc_exit开始执行，而不是直接回到taskA的中断前点——因为中断退出的收尾工作（比如寄存器恢复、异常返回）还没完成，必须先执行svc_exit才能完成整个中断处理流程，最终回到taskA的正常执行路径。

内容的提问来源于stack exchange，提问作者jason