Linux内核抢占与阻塞：模块__exit执行场景技术问询

内核执行上下文基础认知 #

• 进程上下文：可阻塞并释放CPU，随时可被抢占
• 软/硬中断上下文（传统内核）：阻塞时无法触发调度、释放CPU，且抢占被禁用；传统内核中IRQ处理程序内的preempt_disable()属于冗余操作，preempt_enable()无法启用抢占
• PREEMPT_RT内核改动：IRQ处理程序转为线程化的可调度实体，可被抢占但仍不允许阻塞；当前多数Linux发行版已启用PREEMPT_RT
• __init/__exit例程：运行在进程上下文，可被抢占，且二者状态原子互斥（同一时间仅能运行其中一个）

定时器回调与__exit的交互场景 #

传统内核行为 #

在__init中初始化timer_list后返回，定时器触发后的回调运行在软中断上下文。同一CPU上的软中断会被保证完整执行后再切换其他任务，因此不会出现同一CPU上软中断回调执行时被抢占进入__exit、进而在timer_delete_sync()上阻塞的死锁场景——timer_delete_sync()自身不会触发调度，会持续占用CPU。在SMP系统中，若其他CPU进入__exit，可通过timer_delete_sync()阻塞等待回调执行完成。

PREEMPT_RT下的疑问 #

PREEMPT_RT上定时器回调可被抢占，CPU可能转而执行用户空间触发的SYS_delete_module系统调用，进而进入__exit并在timer_delete_sync()上阻塞。相关文档明确说明：

Must be able to sleep on PREEMPT_RT because of the slowpath in del_timer_wait_running().

此处疑问：若timer_delete_sync()自身不主动释放CPU，是否依赖调度器时钟中断触发自动抢占来避免死锁？这种机制的可靠性如何得到保证？

call_usermodehelper()触发模块卸载的同步需求 #

需要使用call_usermodehelper()调用rmmod作为用户空间客户端未响应时的降级方案，使用UHM_NO_WAIT标志让该例程不等待用户空间程序完成。核心诉求是确保模块所有执行逻辑完成后再进入__exit，或在__exit处阻塞等待。

最初误以为call_usermodehelper()会立即执行用户空间程序，导致__exit提前运行，但实际它是将任务加入队列。当前疑问：

• 若call_usermodehelper()是定时器回调的一部分（运行在PREEMPT_RT的软中断上下文，可被抢占），当__exit中阻塞在timer_delete_sync()时，同一CPU上是否不会出现死锁？因为timer_delete_sync()可释放CPU，让剩余的定时器回调得以执行？

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