Re: [RFC PATCH 3/9] module: Place MOD_TEXT before MOD_INIT_TEXT in enumeration

[sashiko-bot@kernel.org]

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 <ardb@kernel.org>

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/20260822135323.795946-11-ardb+git@google.com?part=3