lsmod 仅能展示模块的加载状态，但无法判断模块是否正在被使用、是否经过签名验证或与特定硬件绑定。要全面了解模块的真实状态，必须结合 dmesg、lspci、ethtool、modinfo 等命令进行交叉验证。
lsmod 确实可以列出当前系统已加载的所有内核模块，然而仅凭这一命令，你无法判断模块是否真正处于使用状态、是否拥有有效签名，以及是否与具体硬件绑定。要获取这些深入信息，必须借助其他命令进行逐层排查。
为什么 lsmod 显示模块已加载却无法卸载？
常见场景：执行 rmmod nvidia 报错 Module nvidia is in use，可 lsmod | grep nvidia 的第三列明明显示 0。这到底什么情况？
Used by 0仅表示没有其他模块显式引用该模块，但内核内部可能仍持有引用——例如 GPU 正在执行渲染任务、设备文件处于打开状态，或通过try_module_get()函数手动增加了引用计数。- 真实的占用信息通常隐藏在
dmesg输出中。执行dmesg | tail -20，检查是否出现类似nvidia: module is in use的提示。 - 部分模块具有“常驻”特性，例如
kvm_intel——即使未运行任何虚拟机，它也会保持加载状态，Used by列长期显示为 0，但尝试rmmod卸载时仍会报错。
lsmod | grep xxx 经常遗漏模块？试试这个更高效的匹配方法
直接拿 grep 搜模块名，容易掉坑里。原因不外乎几点：
- 模块名称并不等同于驱动名称或文件名。例如，
nvme_core.ko文件加载后，在lsmod中显示的名称为nvme_core，而非nvme。 - 一个驱动程序通常由多个模块组成（例如
nvidia、nvidia_modeset、nvidia_uvm），仅搜索主名称会遗漏其依赖模块。 grep对大小写敏感，且不支持通配符——例如lsmod | grep nvme*不会产生任何有效结果。
更靠谱的做法是先提取第一列再过滤：
lsmod | awk '{print $1}' | grep -i -E '^(nvme|nvidia|kvm|kysec)'
如何确认模块真正生效？仅靠 lsmod 远远不够
lsmod 只告诉你“代码进了内存”，并不代表驱动已经绑定到设备，也不代表参数已经生效。
- 检查硬件绑定：对于 PCI 设备，执行
lspci -k -s $(lspci | grep -i nvidia | cut -d' ' -f1)查看Kernel driver in use:字段——这才是模块与硬件实际绑定的确凿证据。 - 检查网卡驱动：使用
ethtool -i eth0确认driver字段是否非空，不能仅凭lsmod | grep e1000就断定驱动已生效。 - 验证模块参数是否成功加载：先执行
modinfo -p nvidia | grep NVreg_EnableGpuFirmware，然后对比cat /sys/module/nvidia/parameters/NVreg_EnableGpuFirmware的输出，若不一致则表示参数并未生效。 - 检查安全模块状态：通过
lsmod | grep apparmor看到模块存在还不够，还需运行aa-status确认安全策略已在执行，才能形成完整闭环。
lsmod 未显示预期模块？先排查这三个常见原因
如果预期模块没出现在 lsmod 输出中，别急着重装驱动。先按下面三步排查：
- 模块是否根本未被加载？手动执行
sudo modprobe nvidia && lsmod | grep nvidia进行测试，而非仅依赖开机自动加载——有时仅是加载条件未触发。 - 模块是否被列入黑名单？执行
modprobe --showconfig | grep -A5 'blacklist nvidia'，或检查/etc/modprobe.d/*.conf文件中是否存在blacklist nvidia这一行。 - 模块签名验证不通过？当内核启用
CONFIG_MODULE_SIG_FORCE=y时，未签名的模块会被静默拒绝加载。执行dmesg | grep -i "signature"，若出现module verification failed的提示，则模块自然不会出现在lsmod输出中。
lsmod 只是排查的起点，绝非终点。模块加载仅反映最表层的状态，真正影响系统行为的是：模块是否成功绑定设备、参数是否实际生效、签名是否被接受、依赖关系是否完整——这些深层信息必须借助其他命令逐层深入才能彻底掌握。
