Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] The reordering of `enum mod_mem_type` breaks the `lx-lsmod` GDB script command, causing it to report a core module size of 0 for all loaded modules. --
--- Patch [3]: [RFC PATCH 3/9] module: Place MOD_TEXT before MOD_INIT_TEXT in enumeration --- commit 5a5649e85e950b908f9830e5862b49ac415dfa18 Author: Ard Biesheuvel <[email protected]> module: Place MOD_TEXT before MOD_INIT_TEXT in enumeration This commit reorders enum mod_mem_type so that MOD_TEXT appears right before MOD_INIT_TEXT. This ensures MOD_INIT_TEXT is allocated immediately after MOD_TEXT, reducing fragmentation when truncating allocations in subsequent patches. > diff --git a/include/linux/module.h b/include/linux/module.h > index 7566815fabbe8..0336a46733dd9 100644 > --- a/include/linux/module.h > +++ b/include/linux/module.h > @@ -316,10 +316,10 @@ struct mod_tree_node { > }; > > enum mod_mem_type { > - MOD_TEXT = 0, > - MOD_DATA, > + MOD_DATA = 0, > MOD_RODATA, > MOD_RO_AFTER_INIT, > + MOD_TEXT, [Severity: Medium] Does this reordering break the lx-lsmod GDB script command? In scripts/gdb/linux/modules.py:LxLsmod.invoke(), the total size of a module's core sections is computed by iterating over the memory regions: for i in range(constants.LX_MOD_TEXT, constants.LX_MOD_RO_AFTER_INIT + 1): total_size += module['mem'][i]['size'] Because MOD_TEXT now evaluates to 3 and MOD_RO_AFTER_INIT evaluates to 2 with this change, the Python iteration evaluates to range(3, 3). This generates an empty sequence and the total_size remains 0 for all loaded modules. > MOD_INIT_TEXT, > MOD_INIT_DATA, > MOD_INIT_RODATA, -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
