Linux内核模块卸载：rmmod命令原理、实战与安全规范

1. 项目概述：为什么需要关注rmmod？

在Linux的世界里，内核模块（Kernel Module）就像乐高积木，它们允许我们在不重新编译和重启整个内核的情况下，动态地扩展系统的功能。无论是加载一个新的文件系统驱动、一块特殊的网卡，还是一个内核级的调试工具，都离不开模块。然而，有加载就必然有卸载。rmmod命令，正是这个“拆卸”环节的核心工具。

很多朋友，尤其是刚接触驱动开发或系统调优的同行，常常把注意力放在insmod或modprobe（加载模块）上，认为加载成功就万事大吉。但事实上，模块的卸载过程往往隐藏着更多的“坑”。一个模块如果卸载不干净，轻则导致内存泄漏、资源占用，重则可能引发内核恐慌（Kernel Panic），让系统直接宕机。尤其是在嵌入式开发、云原生底层调优或者自己编写内核模块的场景下，安全、正确地使用rmmod是一项必须掌握的生存技能。

最近，随着国产操作系统和Linux在更多领域的深入应用，对系统底层可控、可维护的要求越来越高。无论是处理“适用于 Linux 的 Windows 子系统”的更新问题，还是排查某个驱动卸载后的残留，亦或是进行安全的系统裁剪，rmmod及其背后的内核模块管理机制，都是我们绕不开的课题。这个命令看似简单，但其背后的原理和注意事项，值得每一个系统工程师、运维开发或驱动开发者仔细琢磨。

2. 内核模块卸载的核心原理与前置知识

在动手敲下rmmod之前，我们必须理解它在内核中触发了什么。这不仅仅是移除一个文件那么简单，而是一个与内核核心紧密互动的复杂过程。

2.1 内核模块的生命周期

一个内核模块从被使用到被抛弃，通常经历以下几个阶段：

1. 编译：将.c源文件编译成.ko（Kernel Object）文件。
2. 加载：通过insmod或modprobe将.ko文件中的代码和数据载入内核地址空间，并执行其初始化函数（通常是module_init指定的函数）。
3. 运行：模块提供的功能（如设备驱动、系统调用）在内核中正常工作。
4. 卸载：通过rmmod触发，内核执行模块的退出函数（module_exit指定的函数），然后从内存中清理掉该模块的所有代码、数据，并释放其占用的所有资源。

rmmod的核心工作，就是触发第4步。如果模块的编写者没有在退出函数里做好“善后”工作，那么卸载就会失败，或者留下隐患。

2.2 rmmod 与 modprobe -r 的区别

这是初学者最容易混淆的一点。我们有两个常用的卸载命令：

• rmmod：低级卸载工具。它只负责卸载一个指定的、当前已经加载的模块。它不处理模块之间的依赖关系。如果你尝试卸载一个正在被其他模块使用的模块，rmmod会直接报错。
• modprobe -r：高级卸载工具。它会递归地检查模块依赖关系。当你执行modprobe -r module_a时，它会尝试卸载module_a，以及那些仅被module_a依赖且现在已无其他模块使用的模块。

如何选择？

• 日常管理：优先使用modprobe -r，因为它更智能、更安全，能自动处理依赖。
• 调试和驱动开发：经常使用rmmod。因为在开发过程中，你需要反复加载和卸载同一个模块来测试，此时你明确知道没有其他依赖，使用rmmod更直接。另外，当模块由于某些原因处于“不可卸载”状态时，rmmod的报错信息往往更直接，有助于定位问题。

2.3 模块状态解读：lsmod 的输出含义

执行lsmod命令，我们可以看到当前已加载的所有模块。它的输出通常有三列：

Module Size Used by e1000e 262144 0 usb_storage 20480 2 joydev 24576 0

• Module：模块名称。
• Size：模块占用的内存大小（字节）。
• Used by：这是理解卸载的关键列。它显示两重信息：
  1. 数字：表示有多少个其他模块正在依赖（使用）这个模块。例如，usb_storage后面的2。
  2. 列表：具体是哪些模块在使用它。如果数字不为0，但后面没有列出模块名，通常表示该模块正被某个进程直接使用（例如，一个文件系统模块正被挂载着）。

一个关键的心得：在卸载模块前，一定要先看lsmod。如果“Used by”列不为0，直接rmmod肯定会失败。你需要先解除这些“使用”状态，比如卸载依赖它的其他模块，或者停止使用该模块功能的进程（例如，卸载文件系统前先umount）。

3. rmmod 命令实战详解与参数解析

掌握了原理，我们来看具体怎么用。rmmod的语法非常简单，但每个参数和场景都有讲究。

3.1 基础命令格式与常用参数

最基本的命令形式是：

sudo rmmod [选项] <模块名>

为什么需要sudo？因为加载和卸载内核模块属于特权操作，直接操作内核内存空间，必须拥有root权限。

常用选项解析：

• -f, --force：强制卸载。这是一个极其危险的操作，仅在极端情况下使用。它会绕过正常的引用计数检查，强制将模块标记为“正在卸载”。如果模块正在被使用，强制卸载几乎必然导致内核崩溃或系统不稳定。在生产环境中，除非你完全清楚后果并有绝对把握，否则永远不要使用-f。
• -w, --wait：等待卸载。如果模块因为“正在被使用”（引用计数>0）而无法立即卸载，-w选项会让rmmod进入等待状态。一旦模块的引用计数降为0（例如，依赖它的进程结束了），rmmod会自动完成卸载。这在编写自动化脚本时很有用。
• -s, --syslog：将错误信息输出到系统日志（syslog），而不仅仅是标准错误输出（stderr）。这在调试无显示界面的服务器时很有帮助。
• -v, --verbose：显示详细的操作信息，让你更清楚卸载过程中发生了什么。

一个实操场景：假设你开发了一个名为my_debug.ko的调试模块，在测试时需要反复卸载加载。

# 查看状态 lsmod | grep my_debug # 正常卸载 sudo rmmod my_debug # 如果因为某个后台测试进程没退出导致卸载失败，可以先尝试结束进程，或者使用-w等待 # 假设我们知道进程会很快自己退出 sudo rmmod -w my_debug # （危险！仅限测试环境，且模块是你自己写的，确认无严重后果时） # 如果模块写的有问题，退出函数卡死，万不得已可以尝试强制卸载（可能导致需要重启） sudo rmmod -f my_debug

3.2 典型操作流程与实例

我们通过几个完整的例子，串联起从检查到卸载的整个流程。

实例1：卸载一个独立的网络驱动模块（如e1000e）假设你的服务器有一张Intel千兆网卡，使用了e1000e驱动，现在想更换驱动或调试。

# 1. 首先，检查模块状态和依赖 lsmod | grep e1000e # 输出可能为：e1000e 262144 0 # “Used by”为0，表示没有其他模块依赖它。 # 2. 检查是否有网络接口正在使用这个驱动 ip link show # 查看网卡名（如ens33）对应的驱动。或者更直接地，查看该网卡是否处于UP状态。 # 如果网卡正在使用，需要先关闭接口 sudo ip link set ens33 down # 3. 现在可以安全卸载 sudo rmmod e1000e # 4. 验证卸载是否成功 lsmod | grep e1000e # 应该没有任何输出。或者使用`dmesg | tail`查看内核日志，通常会有类似`e1000e: NIC Link is Down`和模块卸载成功的日志。

实例2：处理具有依赖关系的模块（如nvidia相关驱动）显卡驱动通常由多个模块组成。

# 1. 查看nvidia相关模块 lsmod | grep nvidia # 输出可能包括：nvidia_uvm, nvidia_modeset, nvidia_drm, nvidia # 并且它们的“Used by”列会形成依赖链。 # 2. 直接卸载核心模块`nvidia`会失败，因为被其他模块使用 sudo rmmod nvidia # rmmod: ERROR: Module nvidia is in use # 3. 正确的顺序是逆着依赖链卸载 sudo rmmod nvidia_drm sudo rmmod nvidia_modeset sudo rmmod nvidia_uvm sudo rmmod nvidia # 或者使用更智能的方式 sudo modprobe -r nvidia_drm # modprobe -r 会自动尝试递归卸载所有相关的模块。

实例3：卸载一个文件系统模块（如fuse）fuse（用户空间文件系统）模块可能被很多用户态程序（如sshfs,rclone）使用。

# 1. 检查使用情况 lsmod | grep fuse # fuse 139264 3 # “Used by”为3，表示有3个“用户”。但这里不一定是其他内核模块，更可能是用户态进程。 # 2. 查找哪些进程在使用fuse sudo lsof /dev/fuse # 或者查看所有挂载的fuse文件系统 mount -t fuse # 或者使用更通用的方法，查看哪个进程打开了`/dev/fuse`设备 sudo lsof | grep /dev/fuse # 3. 终止相关进程或卸载挂载点 # 假设发现是`/mnt/cloud`挂载点 sudo umount /mnt/cloud # 或者终止对应的进程ID（PID） sudo kill -TERM <PID> # 4. 再次检查，确认“Used by”变为0 lsmod | grep fuse # 5. 卸载模块 sudo rmmod fuse

4. 深度排查：当rmmod失败时该怎么办？

rmmod失败是家常便饭，尤其是开发阶段。错误信息是解决问题的钥匙。下面我们系统性地分析常见错误和解决思路。

4.1 常见错误信息与根因分析

4.2 高级诊断工具与技巧

除了基本的命令，还有一些高级工具可以帮助我们深入诊断。

• 查看模块详细信息：

  # 查看模块的所有参数（如果模块有参数的话） sudo modinfo <模块名> # 查看模块在内核符号表中的信息 sudo cat /proc/modules | grep <模块名> # 查看模块的详细状态，包括内存段、引用计数等（非常有用） sudo cat /sys/module/<模块名>/sections/.text sudo cat /sys/module/<模块名>/refcnt

• 使用strace跟踪rmmod系统调用： 当错误信息不明确时，可以用strace跟踪rmmod到底卡在了哪个系统调用上。

  sudo strace rmmod <模块名> 2>&1 | tail -20

  观察最后报错的系统调用，比如delete_module系统调用返回了什么错误码（如EBUSY表示忙）。

• 内核调试与printk： 对于自己编写的模块，最有效的调试方法是在module_exit函数和可能持有引用的地方增加printk日志。

  static void __exit my_exit(void) { printk(KERN_INFO "MyModule: Exit function started.\n"); // ... 释放资源 ... printk(KERN_INFO "MyModule: All resources freed.\n"); }

  卸载后，使用dmesg查看这些日志，可以清晰看到卸载流程是否完整执行。

4.3 模块卸载的“顽固分子”处理

有时，即使lsmod显示“Used by”为0，模块还是卸载不掉。这可能是因为：

1. 内核线程或工作队列（workqueue）未停止：模块创建的内核线程或延迟的工作队列还在运行。必须在退出函数中确保它们被正确停止（kthread_stop()）和销毁（destroy_workqueue()）。
2. 定时器（timer）未删除：如果模块注册了定时器，必须在退出函数中用del_timer_sync()确保定时器被删除。
3. Proc或Sysfs接口未移除：模块在/proc或/sys下创建的接口未清理。需要在退出函数中调用对应的移除函数（如remove_proc_entry,device_destroy）。
4. 引用计数（kref）管理错误：这是驱动开发中最常见的BUG之一。某个数据结构被增加了引用（kref_get），但在某个错误路径或分支中忘记减少引用（kref_put），导致模块的引用计数永远无法归零。

处理心得：遇到“顽固分子”，第一步永远是dmesg看内核日志。第二步是回头审查模块的退出函数，确保它与初始化函数严格对称，所有申请的资源都被释放。第三步，在测试环境中，可以尝试在卸载前手动触发一些可能清理资源的操作（如关闭所有关联的设备文件）。

5. 安全规范、最佳实践与自动化脚本

正确使用rmmod不仅关乎功能，更关乎系统稳定和安全。

5.1 生产环境卸载黄金法则

1. 永远不用-f：重申一遍，在生产服务器上，强制卸载内核模块等同于“自杀式”操作。它可能瞬间导致数据损坏、服务中断且难以诊断。
2. 变更窗口期操作：卸载关键驱动（如存储、网络）模块，必须在计划内的维护窗口进行，并确保有业务中断预案。
3. 卸载前先“静默”：卸载网络驱动前，先down掉网口；卸载存储驱动前，确保相关磁盘无I/O并umount文件系统；卸载USB驱动前，拔掉设备或确保无进程访问。
4. 依赖链逆序操作：手动卸载时，严格遵守从叶子节点到根节点的顺序。使用modprobe -r是更安全的选择。
5. 记录与回滚：卸载任何非系统自带模块前，备份该模块的.ko文件和相关配置文件。如果出现问题，要能快速重新加载回去。

5.2 编写易于卸载的内核模块（开发者视角）

如果你正在开发内核模块，遵循以下原则可以避免绝大多数卸载问题：

• 对称性设计：module_exit函数必须是module_init函数的完美逆过程。初始化时申请了什么资源，退出时就必须按相反顺序释放。
• 处理所有错误路径：在初始化函数中，任何一步失败后，都必须回滚释放之前申请的所有资源。这能保证即使加载失败，模块也能被干净地移除。
• 使用内核基础设施管理资源：尽量使用devm_系列API（Managed Device Resources）申请资源。这些资源会与设备绑定，当设备卸载时自动释放，大大减少资源泄漏的可能。
• 清晰的引用管理：对于复杂的对象关系，使用kref进行引用计数，并在release函数中完成最终的资源释放。

5.3 自动化运维脚本示例

在需要批量管理或自动化测试的场景下，我们可以编写健壮的脚本来处理模块卸载。

#!/bin/bash # 脚本名：safe_rmmod.sh # 描述：安全地卸载一个内核模块，自动处理依赖和等待。 MODULE_NAME=$1 MAX_WAIT=30 # 最大等待时间（秒） if [ -z "$MODULE_NAME" ]; then echo "Usage: $0 <module_name>" exit 1 fi # 检查模块是否已加载 if ! lsmod | grep -q "^${MODULE_NAME}[[:space:]]"; then echo "Module $MODULE_NAME is not loaded." exit 0 fi echo "Attempting to safely remove module: $MODULE_NAME" # 首先尝试使用modprobe -r进行智能卸载 echo "Phase 1: Trying 'modprobe -r'..." if sudo modprobe -r "$MODULE_NAME" 2>/dev/null; then echo "Module $MODULE_NAME and its dependencies removed successfully via modprobe." exit 0 else echo "modprobe -r failed or not available. Falling back to manual check." fi # 手动检查依赖和使用状态 echo "Phase 2: Checking module state..." REF_CNT=$(cat /sys/module/$MODULE_NAME/refcnt 2>/dev/null || echo "N/A") HOLDERS=$(ls /sys/module/$MODULE_NAME/holders/ 2>/dev/null | tr '\n' ' ') echo " Reference count: $REF_CNT" echo " Holders: $HOLDERS" if [ "$REF_CNT" != "0" ] && [ "$REF_CNT" != "N/A" ]; then echo "Module is in use. Waiting for it to become free (max ${MAX_WAIT}s)..." WAITED=0 while [ $WAITED -lt $MAX_WAIT ]; do sleep 1 REF_CNT=$(cat /sys/module/$MODULE_NAME/refcnt 2>/dev/null || echo "N/A") if [ "$REF_CNT" = "0" ]; then echo "Module is now free to remove." break fi WAITED=$((WAITED + 1)) done if [ $WAITED -eq $MAX_WAIT ]; then echo "ERROR: Module still in use after ${MAX_WAIT} seconds. Aborting." echo "You may need to manually stop processes using:" echo " sudo lsof | grep /dev/... # 查找相关设备文件" echo " or check holders: $HOLDERS" exit 1 fi fi # 最终尝试卸载 echo "Phase 3: Final removal with rmmod..." if sudo rmmod "$MODULE_NAME"; then echo "Module $MODULE_NAME removed successfully." else echo "ERROR: Failed to remove module $MODULE_NAME." echo "Last kernel messages:" dmesg | tail -5 exit 1 fi

这个脚本体现了安全卸载的完整思路：先尝试高级工具，再检查状态并等待，最后才执行底层命令，并在失败时提供诊断线索。