lsmod是唯一实时反映内核已加载模块的命令，读取/proc/modules输出真实运行状态；它不显示内置驱动、不体现硬件绑定或参数生效情况，单靠它易误判。
lsmod 是唯一能实时反映当前内核中已加载模块的命令，它读取 /proc/modules，输出真实运行状态，不是磁盘文件列表，也不是启动时的静态快照。
为什么 lsmod | grep xxx 总是找不到模块？
直接 grep 模块名容易漏匹配，因为：
- 模块名不等于驱动名或文件名：
nvme_core.ko加载后显示为nvme_core，不是nvme - 一个硬件驱动常拆成多个模块：比如
nvidia通常伴生nvidia_modeset、nvidia_uvm，只搜主名会丢依赖项 - 模块名严格小写且不含路径或
.ko后缀：insmod ./hello.ko后，lsmod只显示hello -
grep nvme*无效——lsmod输出不支持 shell 通配符
稳妥做法是先提取第一列再正则过滤：
lsmod | awk '{print $1}' | grep -E '^(nvme|nvidia|kvm|usb)'
Used by 列为 0 就能卸载吗？
不能。数字 0 只表示没有其他模块显式引用它，不代表内核没内部持有：
-
rmmod nvidia报错Module nvidia is in use很常见，哪怕第三列是 0 - GPU 正在渲染、设备节点被打开（如
/dev/nvidiactl）、或内核代码调用try_module_get()都会导致占用 - 某些模块（如
kvm_intel）设计为常驻，rmmod必然失败，和Used by值无关
真要确认是否可卸载，得看 dmesg | tail -20，找类似 nvidia: module is in use 的提示。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
模块没出现在 lsmod 输出里，可能根本没加载
lsmod 空了 ≠ 模块不存在，只是没进内核。排查顺序应该是：
- 手动触发加载：
sudo modprobe nvidia && lsmod | grep nvidia，别只等开机自动加载 - 检查是否被黑名单：
modprobe --showconfig | grep -A5 'blacklist nvidia'或翻/etc/modprobe.d/*.conf - 确认签名是否被拒：若内核启用了
CONFIG_MODULE_SIG_FORCE=y，未签名模块会被静默拒绝，dmesg | grep -i signature会报错 - 验证模块文件是否存在：
modprobe -l | grep nvidia查磁盘上有没有，输出为空说明depmod -a没跑过，或/lib/modules/$(uname -r)根本没对应目录
想确认驱动是否真正生效，不能只看 lsmod
lsmod 只告诉你“代码进了内存”，不代表驱动绑定了设备或参数起了作用：
- 查 PCI 设备绑定：
lspci -k -s $(lspci | grep -i nvidia | cut -d' ' -f1)，看Kernel driver in use:字段 - 查网卡驱动：
ethtool -i eth0，确认driver非空 - 查模块参数是否加载成功：
modinfo -p nvidia | grep NVreg_EnableGpuFirmware，再对比cat /sys/module/nvidia/parameters/NVreg_EnableGpuFirmware - 安全模块（如 AppArmor）需额外验证：
lsmod | grep apparmor成功后，还得aa-status才算闭环
最易被忽略的是：lsmod 不显示内置驱动（built-in）、不体现硬件绑定、也不反映签名或参数实际生效状态。靠它单打独斗，十有八九会误判。
