On Wed, Sep 30, 2026 at 5:25 AM Hao Ge <[email protected]> wrote: > > Hi Suren and Andrew > > > On 2026/9/30 10:39, Suren Baghdasaryan wrote: > > On Tue, Sep 29, 2026 at 8:44 PM Andrew Morton <[email protected]> > > wrote: > >> > >> On Tue, 29 Sep 2026 16:20:07 +0800 Hao Ge <[email protected]> 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? > > Thanks, I've just gone through this carefully. > > > > > I think vmalloc fix in patch#2 should be posted separately and clearly > > quialifies for backporting as if fixes issues Hao found at [1]. > > Agreed. Patch #2 was added to this patch series because > vm_module_tags_populate > suffers from the same issue. If we want to be more conservative, I'd prefer > to keep > vm_module_tags_populate as it was in V10: > https://lore.kernel.org/all/[email protected]/
I disagree with this approach. That means we are introducing an extra code inside vm_module_tags_populate() only to clean it up later. Instead please post Patch #2 separately. That posting should have your current patch that changes vmap_pages_xxx() to clean up on failure, followed by patch(es) which remove unnecessary cleanup that some functions currently perform by themselves. This patchset should definitely be tagged for stable. Once that patchset is accepted, the rest of your current patchset fixing alloc_tags can be posted with correct assumption that vmap_pages_range() cleans up its partial mapping when it fails. I know this sequence will take longer to upstream but I think it's the right way to go. > > Then we can submit a fix for __GFP_NOFAIL retry loop in __vmalloc_area_node() > as a hotfix together > with our new patch #2. While at it, we can also check if there are any > unnecessary calls to > vunmap_range family functions that can be cleaned up now that patch #2 is > applied. > > > > > > 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. > > Thanks, sorry for all the hassle on you folks. > > Thanks > Best Regards > Hao > > > > > [1] > > https://lore.kernel.org/all/[email protected]/ > > > >> > >> Also, Sashiko has been busy again: > >> > >> https://sashiko.dev/#/patchset/[email protected]
