Re: [PATCH v11 0/7] alloc_tag and module codetag section fixes

[Andrew Morton]

On Tue, 29 Sep 2026 16:20:07 +0800 Hao Ge <hao.ge@xxxxxxxxx> wrote:

> With profiling toggled off, the overflow check in
> reserve_module_tags() did not run, a module could load with more
> tags than the page flags can address, and re-enabling profiling
> then silently corrupted /proc/allocinfo. On overflow the fix shuts
> profiling down, releases the reservation and returns -EAGAIN, and
> the codetag section lands as regular module data in the same load,
> so the module loads without profiling.
> 
> Review of the earlier series by Sashiko turned up more problems.
> 
> One is a race. layout_sections() and move_module() both asked
> codetag_needs_module_section() where a codetag section goes, and
> mem_profiling_support can change between the two calls, for instance
> when another module load overflows the tag index and shuts profiling
> down. move_module() then copied the codetag section to offset 0 of
> its regular destination and clobbered the first section placed in
> that region.
> 
> v7 reworks where codetag sections are allocated, on a prototype by
> Petr Pavlu [1]. The allocation runs before layout_sections() and the
> placement is decided in one step, so nothing re-asks the question
> and the race is gone. The retry is gone too, on -EAGAIN the section
> is laid out as regular module data right in the same load.

Thanks.

Seven patches, all cc:stable.  Why is a backport proposed? 
Documentation/process/stable-kernel-rules.rst gives guidelines - does
this series meet them?  Does Suren have thoughts?

Also, Sashiko has been busy again:
	https://sashiko.dev/#/patchset/20260929082014.160587-1-hao.ge@xxxxxxxxx