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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.