Re: [RFC PATCH 3/9] module: Place MOD_TEXT before MOD_INIT_TEXT in enumeration
From: sashiko-bot@kernel.org
Date: 2026-08-22 14:05:51
Also in:
linux-trace-kernel
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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/20260822135323.795946-11-ardb+git@google.com?part=3