On 12/29/25 3:45 AM, Yafang Shao wrote: > We maintain a vmcore analysis script on each server that automatically > parses /var/crash/XXXX/vmcore-dmesg.txt to categorize vmcores. This helps > us save considerable effort by avoiding analysis of known bugs. > > For vmcores triggered by a driver bug, the system calls print_modules() to > list the loaded modules. However, print_modules() does not output module > version information. Across a large fleet of servers, there are often many > different module versions running simultaneously, and we need to know which > driver version caused a given vmcore. > > Currently, the only reliable way to obtain the module version associated > with a vmcore is to analyze the /var/crash/XXXX/vmcore file itself—an > operation that is resource-intensive. Therefore, we propose printing the > driver version directly in the log, which is far more efficient. > > - Before this patch > > Modules linked in: xfs nvidia-535.274.02(PO) nvme_core-1.0 mlx_compat(O) > Unloaded tainted modules: nvidia_peermem(PO):1 > > - After this patch > > Modules linked in: xfs nvidia(PO) nvme_core mlx_compat(O) > Unloaded tainted modules: nvidia_peermem(PO):1 I feel that module versions are not particularly useful for in-tree modules nowadays. They rarely change and therefore provide little information about what code is actually running.
This is supported by their limited use in the kernel. In v6.19-rc3, I see the following: $ git grep '^MODULE_LICENSE(.*);$' | wc -l 12481 $ git grep '^MODULE_VERSION(.*);$' | wc -l 605 Moreover, in the event of a crash, the log should contain the kernel version and usually also the vmlinux build ID, which should provide enough information to identify in-tree modules. However, based on the example in your patch description, it seems to me that your main interest is likely in identifying external modules. If that is correct, I see why it might be helpful to quickly identify their versions. This assumes that developers of external modules actually update MODULE_VERSION() in their releases, but I don't know if this is generally true. As mentioned, most in-tree modules do not specify an explicit version, so in terms of bloating the information about loaded modules, the patch should have minimal impact in practice. Alternatively, the version information could be printed only for external modules. -- Thanks, Petr
