From: Hao Ge <hao.ge@linux.dev>
To: Andrew Morton <akpm@linux-foundation.org>,
Suren Baghdasaryan <surenb@google.com>
Cc: Kent Overstreet <kent.overstreet@linux.dev>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v2 0/2] alloc_tag: fix a leak and a deadlock around shutdown_mem_profiling()
Date: Fri, 28 Aug 2026 11:11:19 +0800 [thread overview]
Message-ID: <afa606df-3d5b-47c2-9972-f3e0c2e13c12@linux.dev> (raw)
In-Reply-To: <20260826203914.347c42aa00081ee9e0eb858a@linux-foundation.org>
Hi Andrew
On 2026/8/27 11:39, Andrew Morton wrote:
> On Mon, 17 Aug 2026 14:27:24 +0800 Hao Ge <hao.ge@linux.dev> wrote:
>
>> Two fixes for issues reported by sashiko:
>>
>> 1. percpu counter leak on modules loaded after profiling is disabled.
>> 2. AB-BA deadlock between module load and /proc/allocinfo readers.
>>
>
> Thanks. AI review asked two questions. One pertinent to your
> alterations and one pertinent to Suren ;)
>
> https://sashiko.dev/#/patchset/20260817062726.106511-1-hao.ge@linux.dev
>
> I'll queue the patchset for 7.3-rc1, with a note-to-self.
Thanks for the heads up on the sashiko review questions.
The question on patch 1 (codetag_load_module() error handling)
has two parts.
The lost error code issue is already fixed; I sent the patch and
you queued it. (Thanks).
For the rollback part:
I've also seen Sashiko flag this same issue on another of my patches.
At the moment this case can't actually happen, alloc_tag is our only
registered codetag type, and codetag_module_init() cleans up its cmod
from the idr on every failure path, so nothing gets left behind.
That said, if we ever add a second codetag type down the line, the problem
Sashiko spotted will become real. I will follow up later to refine this
logic and make it more robust.
The question on patch 2 (async /proc/allocinfo removal racing with
alloc_tag_init() failure):
When I first read it, I think the window is unreachable. It requires
alloc_tag_init() to fail after proc_create() succeeded, and a process
to open and read /proc/allocinfo in the gap between schedule_work()
and the work running on system_wq.
But CONFIG_MEM_ALLOC_PROFILING is a bool, so when enabled alloc_tag is
always built in and it cannot be a loadable module. Its module_init(alloc_tag_init)
runs inside do_initcalls(), before /init is exec'd. Failures inside
alloc_tag_init() are already very unlikely to happen. When the failure
happens, no normal userspace exists yet.
That said, I realised the fix would actually be quite simple, we could just
move proc_create() to the end of alloc_tag_init().
I am not entirely sure whether we should do this though.
Suren, what is your opinion?
Thanks
Best Regards
Hao
next prev parent reply other threads:[~2026-08-28 3:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 6:27 Hao Ge
2026-08-17 6:27 ` [PATCH 1/2] alloc_tag: skip percpu counter allocation when profiling is disabled Hao Ge
2026-08-24 16:44 ` Suren Baghdasaryan
2026-08-17 6:27 ` [PATCH 2/2] alloc_tag: remove /proc/allocinfo outside of mod_lock Hao Ge
2026-08-24 16:46 ` Suren Baghdasaryan
2026-08-27 3:39 ` [PATCH v2 0/2] alloc_tag: fix a leak and a deadlock around shutdown_mem_profiling() Andrew Morton
2026-08-28 3:11 ` Hao Ge [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-08-17 6:27 Hao Ge
2026-08-17 6:26 Hao Ge
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=afa606df-3d5b-47c2-9972-f3e0c2e13c12@linux.dev \
--to=hao.ge@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®