Re: [RFC PATCH v6 2/2] module: allocate codetag sections before the regular module layout

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Percpu counters are permanently leaked when a codetag section falls back to regular module memory.
--

commit 67e030141d036ccecf172380286b7317fac48a51
Author: Hao Ge <hao.ge@linux.dev>

module: allocate codetag sections before the regular module layout

This patch moves codetag section allocation to occur before the regular
module layout and fails the load on allocation errors. However, on tag
area overflow, it gracefully falls back to allocating the codetag section
in regular module memory instead.

> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index d0e1e0bd2ad06..da80f7c187921 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c

[ ... ]

> @@ -2951,9 +2906,48 @@ static bool blacklisted(const char *module_name)
>  }
>  core_param(module_blacklist, module_blacklist, charp, 0400);
>  
> +/*
> + * Allocate codetag sections separately. They are loaded into preallocated
> + * contiguous memory because they may still be used after the module is
> + * unloaded.
> + *
> + * If the separate allocation overflows, allocate the section normally
> + * so that the module can still be loaded.
> + */
> +static int allocate_codetag_sections(struct load_info *info)
> +{
> +	for (unsigned int i = 1; i < info->hdr->e_shnum; i++) {
> +		Elf_Shdr *shdr = &info->sechdrs[i];
> +		const char *sname = info->secstrings + shdr->sh_name;
> +		void *dest;
> +
> +		if (!codetag_needs_module_section(info->mod, sname, shdr->sh_size))
> +			continue;
> +
> +		dest = codetag_alloc_module_section(info->mod, sname, shdr->sh_size,
> +				arch_mod_section_prepend(info->mod, i), shdr->sh_addralign);
> +		if (WARN_ON(!dest))
> +			return -EINVAL;
> +		if (dest == ERR_PTR(-EAGAIN))
> +			/* Allocate the section as a regular section. */
> +			continue;

[Severity: High]
If reserve_module_tags() returns -EAGAIN due to reaching the tag addressable
limit, the module load proceeds by falling back to regular module memory.
However, does this cause a permanent percpu memory leak when the module is
eventually unloaded?

When the codetag section falls back to regular memory, the module is never
added to the mod_area_mt maple tree. Later, load_module() in mm/alloc_tag.c
unconditionally allocates percpu memory for all tags in the module:

mm/alloc_tag.c:load_module() {
    ...
    for (tag = start_tag; tag < stop_tag; tag++) {
        ...
        tag->counters = alloc_percpu(struct alloc_tag_counters);
    }
}

During unload, release_module_tags() attempts to free these counters. But
since the module was never added to the maple tree, it exits early before
cleaning up the counters:

mm/alloc_tag.c:release_module_tags() {
    ...
    mas_for_each_rev(&mas, val, 0)
        if (val == mod)
            break;

    if (!val) /* module not found */
        goto out;
    ...
}

Will this cause all percpu counters allocated for this module to be leaked,
potentially leading to percpu memory exhaustion over time?

> +		if (IS_ERR(dest))
> +			return PTR_ERR(dest);
> +
> +		if (shdr->sh_type != SHT_NOBITS)
> +			memcpy(dest, (void *)shdr->sh_addr, shdr->sh_size);
> +		shdr->sh_addr = (unsigned long)dest;
> +		shdr->sh_flags &= ~(unsigned long)SHF_ALLOC;
> +		shdr->sh_entsize = SH_ENTSIZE_STANDALONE;
> +	}
> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831072104.120197-1-hao.ge@linux.dev?part=2