From: Hongling Zeng <zhongling0719@126.com>
To: Qi Zheng <qi.zheng@linux.dev>,
Hongling Zeng <zenghongling@kylinos.cn>,
akpm@linux-foundation.org, david@fromorbit.com,
roman.gushchin@linux.dev, muchun.song@linux.dev
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] mm: shrinker: Fix double-free in alloc_shrinker_info error path
Date: Sat, 11 Jul 2026 15:53:20 +0800 [thread overview]
Message-ID: <6A51F670.9020104@126.com> (raw)
In-Reply-To: <ab1bdfa0-7382-4d26-a65d-68eb172eb84a@linux.dev>
在 2026年07月11日 13:31, Qi Zheng 写道:
> Hi Hongling,
>
> On 7/11/26 12:19 PM, Hongling Zeng wrote:
>> In alloc_shrinker_info(), when shrinker_unit_alloc() fails for a node,
>> the error handler calls free_shrinker_info() which iterates over ALL
>> nodes and tries to free their shrinker_info. For the failed node,
>> rcu_assign_pointer() was skipped, so its shrinker_info still points
>> to old data. This causes double-free of valid shrinker_info structures.
>
> No, it will be NULL, not old data. Therefore, the double-free you
> mentioned doesn't exist. Before sending the fix, please verify the
> problem exists and your fix actually works.
>
Sorry, You're absolutely right. After carefully re-examining the code,
I now see that:
1. alloc_mem_cgroup_per_node_info() allocates with __GFP_ZERO, so
shrinker_info is initialized to NULL, not old data
2. The error handler in alloc_shrinker_info() correctly bounds
cleanup with if (nid >= failed_nid) break;, so it only frees
successfully allocated structures
My analysis was incorrect - there is no double-free issue in this
code path, I apologize for submitting this patch without proper
verification.
> And as a reminder, please don't repeatedly send identical patches:
>
> 1.
> https://lore.kernel.org/all/20260711041509.92926-1-zenghongling@kylinos.cn/
> 2.
> https://lore.kernel.org/all/20260711041823.95135-1-zenghongling@kylinos.cn/
> 3.
> https://lore.kernel.org/all/20260711041954.95749-1-zenghongling@kylinos.cn/
>
> One last thing, please make sure to base your changes on the latest
> tree.
>
> Thanks,
> Qi
I also apologize for the multiple identical submissions ,my email
client was reporting errors when sending, so I retried thinking the
emails weren't going through。
>
>>
>> Fix by tracking which node failed and only freeing shrinker_info
>> structures that were successfully assigned via rcu_assign_pointer()
>> in this call. Failed/unhandled nodes are left untouched.
>>
>> Fixes: 15e8156713cc ("mm: shrinker: avoid memleak in
>> alloc_shrinker_info")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
>> ---
>> mm/shrinker.c | 13 ++++++++++++-
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/shrinker.c b/mm/shrinker.c
>> index 7082d01c8c9d..92c6cb455fc9 100644
>> --- a/mm/shrinker.c
>> +++ b/mm/shrinker.c
>> @@ -78,6 +78,7 @@ int alloc_shrinker_info(struct mem_cgroup *memcg)
>> {
>> int nid, ret = 0;
>> int array_size = 0;
>> + int failed_nid;
>> mutex_lock(&shrinker_mutex);
>> array_size = shrinker_unit_size(shrinker_nr_max);
>> @@ -98,8 +99,18 @@ int alloc_shrinker_info(struct mem_cgroup *memcg)
>> return ret;
>> err:
>> + failed_nid = nid;
>> + for_each_node(nid) {
>> + struct shrinker_info *info;
>> +
>> + if (nid >= failed_nid)
>> + break;
>> + info = shrinker_info_protected(memcg, nid);
>> + rcu_assign_pointer(memcg->nodeinfo[nid]->shrinker_info, NULL);
>> + shrinker_unit_free(info, 0);
>> + kvfree(info);
>> + }
>> mutex_unlock(&shrinker_mutex);
>> - free_shrinker_info(memcg);
>> return -ENOMEM;
>> }
next prev parent reply other threads:[~2026-07-11 7:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-11 4:19 [PATCH] mm: shrinker: Fix double-free in alloc_shrinker_info error path Hongling Zeng
2026-07-11 5:31 ` Qi Zheng
2026-07-11 7:53 ` Hongling Zeng [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-07-11 4:18 [PATCH] mm: shrinker: fix " Hongling Zeng
2026-07-11 9:47 ` kernel test robot
2026-07-11 13:27 ` kernel test robot
2026-07-11 4:15 Hongling Zeng
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=6A51F670.9020104@126.com \
--to=zhongling0719@126.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=qi.zheng@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=stable@vger.kernel.org \
--cc=zenghongling@kylinos.cn \
/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.