[Crash-utility] Re: [PATCH 0/1] Recover modules from a damaged modules list

Hi Chao, On 11/3/26 3:30 PM, Chao Huang wrote: > Hi, > > A dumpfile may contain readable struct module objects while a missing > or corrupt list node prevents crash from walking the global modules > list. The current behavior sets NO_MODULE_ACCESS, so "mod -S" cannot > load symbols for any of the remaining modules. > > The module_kset list provides an independent path to the same loaded > module objects on KMOD_V2 kernels. The patch uses it only after normal > module access fails and only for dumpfiles. Live kernels keep using the > existing path, avoiding addresses that may become stale. > > The recovery reuses do_list() and the existing hash queue. It accepts > the readable prefix of a damaged module_kset list, which is useful for > incomplete dumps. Entries with module_kobject.mod == NULL are skipped. > They are sysfs objects for built-in modules, where THIS_MODULE is NULL. > For non-NULL entries, the embedded module.mkobj backlink is validated > before the struct module address is accepted. > > Module symbol collection performs a second pass. The recovered > addresses are therefore kept in a local array and passed explicitly to > the symbol storage functions. This avoids adding persistent state to > kernel_table. Both the pre-6.4 layout and the module.mem layout added > in Linux 6.4 use the same recovered list. If no module is recovered, > the existing NO_MODULE_ACCESS behavior is preserved. > > Tested with: > > - ARM64 build: make target=ARM64 -j40 > - Complete Linux 6.18 sysrq dump: 278 module objects loaded without the > fallback path. > - Incomplete dump: 473 module_kset entries were scanned. The fallback > recovered 346 loaded modules, skipped 126 built-in objects and one > unreadable entry, and "mod -S" loaded the available module symbols. > > Only the recovery result is reported by the new code. Its wording > distinguishes loaded modules from built-in kobjects and applies to both > the pre-6.4 and 6.4+ module memory layouts. I have not looked into code details, I need more time, please address Kazu's comment in another reply. But I have a few thoughts below: 1. This patch changes the original logic, from a no module access at all to partial recovered module access, how about make it disabled by default and enable via command options eg. --recover-module-kset. And Add a flag eg. MODULES_PARTIAL, so that if bt or other command can not find symbols (some modules could missing) it can handle it gracefully. 2. the kset walking could be resued somewher else, so it would be better to implement a general kset_walk(), the module case can just call it like: kset_walk("module_kset", callback)

> > Comments are welcome. > > wya (1): > kernel: recover modules from module_kset > > defs.h | 7 ++- > kernel.c | 175 ++++++++++++++++++++++++++++++++++++++++++++++++++---- > symbols.c | 33 ++++++++-- > 3 files changed, 195 insertions(+), 20 deletions(-) >