lsmod仅确认模块加载，不保证硬件绑定或功能启用；需配合modinfo查参数/路径/签名，再用lspci、ethtool、dmesg验证设备绑定与probe状态。
直接运行 lsmod 就能列出所有已加载的内核驱动模块——它读的是 /proc/modules，结果实时、可靠、无需 root 权限。
为什么不能只看 lsmod | grep 驱动名就认为驱动在用
模块加载 ≠ 设备正在使用它。常见断点：
-
lsmod | grep nvme有输出，但lspci -k -s 0000:01:00.0显示Kernel driver in use: none→ 实际被vfio-pci抢占了设备 -
lsmod | grep igb成功，但ethtool -i eth0的driver字段为空或unknown→ 驱动没注册netdev，probe 阶段失败，dmesg | grep -i igb通常会报probe failed - 模块名大小写敏感，且不含扩展名：你编译的
hello.ko加载后在lsmod里只显示为hello；而insmod ./hello.ko若没定义MODULE_ALIAS，就不会出现在列表中
lsmod 输出里 Size 和 Used by 到底怎么看
Module 列不是驱动名，而是模块名（比如 nvme 模块对应设备可能是 nvm0n1）；Size 是内存占用字节数，数值异常小（如 12676）可能表示只是封装层；Used by 为 0 不代表模块空闲——它可能正被内核子系统隐式持有（例如 nf_conntrack 被 netfilter 框架内部引用，不会显示在该列）
若某模块出现在多行 Used by 的依赖链中（如 nf_nat 同时被 xt_nat 和 nf_nat_masquerade_ipv4 引用），说明它是共享基础模块，强行 rmmod 会导致 panic
查完 lsmod 还得补哪几手才算闭环
仅靠 lsmod 无法确认参数、签名、硬件绑定或版本匹配，必须组合验证：
- 用
modinfo -p <code>模块名查可调参数（如modinfo -p igb显示InterruptThrottleRate，是调优网卡中断的关键入口） - 用
modinfo -n <code>模块名看模块文件路径，验证是否来自当前内核版本（避免/lib/modules/5.15.0-101-generic/下混入旧版.ko） - 用
modinfo -F sig_id <code>模块名检查签名 ID，若输出为空且内核启用了CONFIG_MODULE_SIG_FORCE=y，该模块根本无法加载 - 用
lspci -k或lsusb -t确认设备是否真正绑定到该驱动，这才是“驱动在用”的最终证据
真正容易被忽略的是：模块加载成功只是第一步，lsmod 只告诉你“代码进了内核”，不保证“设备连上了、probe 完了、netdev 注册了、参数生效了”。每一步都可能断在中间，得靠 dmesg + ethtool + lspci -k 交叉印证。
