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

[Suren Baghdasaryan]

On Tue, Sep 29, 2026 at 8:44 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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?

I think vmalloc fix in patch#2 should be posted separately and clearly
quialifies for backporting as if fixes issues Hao found at [1].

The rest are also bug fixes but their size is concerning. I'll review
them first before advising on which ones should be backported. Some
fixes address issues that happen very rarely and if a fix is too
complex it might make sense to leave it be or fix it some other way
with less churn. Please give me a couple of days to review them. With
the upcoming LPC I'm trying to multiplex between several projects.

[1] https://lore.kernel.org/all/b8005c24-ecac-45c4-840a-fd282f9693b5@xxxxxxxxx/

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