lsmod输出三列：module为模块名，size为模块大小（字节），used by为引用计数及依赖模块列表；例如“nvidia 26214400 87 nvidia_uvm,nvidia_drm”表示该模块占25 mib、被87处引用且依赖于后两个模块。
lsmod 输出每列代表什么
执行 lsmod 后，输出三列：模块名、大小（字节）、被引用次数及依赖模块列表。例如某行显示 nvidia 26214400 87，说明 nvidia 模块占 25 MiB 内存，当前被 87 个地方引用（含子模块），若后面还有逗号分隔的模块名（如 nvidia_uvm,nvidia_drm），表示它正被这些模块依赖。
注意：第三列数字为 0 并不意味着模块“空闲”，只是没有其他模块显式调用它；但若该模块正被设备或进程使用（比如 GPU 正在渲染），rmmod 仍会失败——此时需看 dmesg | tail 的报错，常见提示是 Module nvidia is in use。
grep 过滤时为什么找不到模块名
模块名可能被截断或带下划线变体。例如 nvme 驱动实际加载后常显示为 nvme_core、nvme、nvme_pci，直接 lsmod | grep nvme 可能漏掉 nvme_core；更稳妥的是 lsmod | awk '{print $1}' | grep -E '^(nvme|nvidia|usb)' 。
另一个常见原因是模块名大小写敏感，且不含路径或扩展名：hello.ko 加载后只显示为 hello；而 modprobe hello 才能正确匹配，insmod ./hello.ko 不会出现在 lsmod 名称列中（除非模块内定义了 MODULE_ALIAS）。
-
lsmod只显示已成功插入内核的模块，不显示仅存在于磁盘的 .ko 文件 - 模块若被标记为
tainted（比如闭源驱动），会在/proc/modules对应行末尾标T，但lsmod默认不显示该标志 - 某些安全加固内核（如启用了
CONFIG_MODULE_SIG_FORCE）会拒绝加载无签名模块，此时insmod报错Operation not permitted，但lsmod里自然也不会出现
modprobe 和 insmod 的关键区别在哪
modprobe 查模块名，自动找路径、解依赖、读参数配置；insmod 查文件路径，不处理依赖，也不读 /etc/modprobe.d/ 规则。实际中几乎不用 insmod，除非你明确知道模块无依赖、且内核版本与模块编译环境严格一致。
比如加载 veth 模块：sudo modprobe veth 会顺带拉起 cfg80211（如果尚未加载）；而 sudo insmod /lib/modules/$(uname -r)/kernel/net/veth.ko 若缺少 cfg80211，会直接报 Unknown symbol in module。
-
modprobe -r卸载时自动递归卸载依赖模块，rmmod只卸载指定名称，若依赖未清空会失败 -
modprobe --showconfig能看到该模块是否被blacklist或install指令覆盖，这是排查“明明有模块却死活加载不上”的关键入口 -
insmod加载失败后，模块文件可能已部分载入，导致后续modprobe也卡住，此时需先sudo dmesg | tail -20确认状态，再考虑重启或sudo rmmod -f强制清理（有风险）
哪些地方会静默加载模块，容易被忽略
模块不一定靠人手动敲命令加载。udev 设备事件、systemd service 启动、甚至挂载文件系统（如 mount -t ext4）都可能触发 modprobe。这意味着你没运行过任何加载命令，lsmod 里也可能突然多出 ext4、usb_storage 等模块。
真正控制“开机就加载”的配置不在 /etc/modules 就是 /etc/modules-load.d/*.conf；但要注意：这些只是告诉 systemd 在 early boot 阶段调用 modprobe，如果模块因依赖缺失或签名失败而加载失败，systemd 不报错，lsmod 里也不会出现，只能查 journalctl -b | grep -i "modprobe\|failed"。
另外，虚拟化场景下（KVM/QEMU），kvm_intel 或 kvm_amd 常被 qemu-system-x86_64 自动触发加载，但如果你禁用了 BIOS 中的 VT-x/AMD-V，模块虽存在却无法初始化，lsmod 里看不到它，dmesg 却会有 kvm: disabled by bios 提示。
