From: Andrew Morton <akpm@linux-foundation.org>
To: Hao Ge <hao.ge@linux.dev>
Cc: Suren Baghdasaryan <surenb@google.com>,
Luis Chamberlain <mcgrof@kernel.org>,
Petr Pavlu <petr.pavlu@suse.com>,
Daniel Gomez <da.gomez@kernel.org>,
Sami Tolvanen <samitolvanen@google.com>,
Aaron Tomlin <atomlin@atomlin.com>,
linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v4 0/2] alloc_tag: fix undetected compressed tag overflow when profiling is disabled
Date: Mon, 10 Aug 2026 20:52:51 -0700 [thread overview]
Message-ID: <20260810205251.3fce0ec86ee20925fd577c26@linux-foundation.org> (raw)
In-Reply-To: <20260810093955.153015-1-hao.ge@linux.dev>
On Mon, 10 Aug 2026 17:39:53 +0800 Hao Ge <hao.ge@linux.dev> wrote:
> v3 was a single patch. After discussion with Suren and Andrew we went
> for a more graceful approach: rather than failing the module load on
> overflow, let it load without profiling. Once profiling is disabled,
> codetag_needs_module_section() returns false, so on retry the codetag
> section is placed as regular module data.
>
> A new patch (1/2) is added to move release_module_tags() above
> reserve_module_tags(), since the overflow path now has to call it and
> the helper sits below it.
Thing is, [2/2] has cc:stable but it requires [1/2] to be able to be
compiled. [1/2] doesn't have cc:stable so we're asking -stable folks
to backport a patch which doesn't compile.
Resolve this by using the same Fixes: and cc:stable in both patches.
> release_module_tags() is what module unload calls to drop a module's
> reservation from the maple tree. By the time reserve_module_tags()
> detects the overflow it has already stored that reservation, and the
> -EAGAIN return skips vm_module_tags_populate(), so the backing pages
> never get mapped. If reserve_module_tags() returns without calling
> release_module_tags(), the stale entry keeps pointing at that unmapped
> range; when the module is later unloaded, release_module_tags() walks
> it and panics.
AI review had a lot to say about this patchset. Some pre-existing, some
not:
https://sashiko.dev/#/patchset/20260810093955.153015-1-hao.ge@linux.dev
offtopic: alloc_tag isn't getting allmodconfig build coverage at this
time because:
1: MEM_ALLOC_PROFILING depends on !DEBUG_FORCE_WEAK_PER_CPU (why? I
can't figure that out)
2: x86_64 allmodconfig enables DEBUG_FORCE_WEAK_PER_CPU, despite it
being for s390 and alpha. In fact it might be alpha-only.
Adding
depends on ALPHA || S390
in there fixes this.
prev parent reply other threads:[~2026-08-11 3:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 9:39 [PATCH v4 0/2] alloc_tag: fix undetected compressed tag overflow when profiling is disabled Hao Ge
2026-08-10 9:39 ` [PATCH v4 1/2] alloc_tag: move release_module_tags() above reserve_module_tags() Hao Ge
2026-08-10 10:03 ` sashiko-bot
2026-08-10 9:39 ` [PATCH v4 2/2] alloc_tag: fix undetected compressed tag overflow when profiling is disabled Hao Ge
2026-08-10 10:03 ` sashiko-bot
2026-08-11 3:52 ` Andrew Morton [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260810205251.3fce0ec86ee20925fd577c26@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=atomlin@atomlin.com \
--cc=da.gomez@kernel.org \
--cc=hao.ge@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=petr.pavlu@suse.com \
--cc=samitolvanen@google.com \
--cc=surenb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.