From: Muchun Song <muchun.song@linux.dev>
To: chenridong <chenridong@huawei.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
akpm@linux-foundation.org, david@fromorbit.com,
zhengqi.arch@bytedance.com, roman.gushchin@linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
wangweiyang2@huawei.com
Subject: Re: [PATCH v2] mm: shrinker: avoid memleak in alloc_shrinker_info
Date: Wed, 16 Oct 2024 10:21:30 +0800 [thread overview]
Message-ID: <FD2AA126-5885-41C7-ACFD-85C764170B9E@linux.dev> (raw)
In-Reply-To: <4a18e997-3a94-4248-8923-c3764d12b0d6@huawei.com>
> On Oct 16, 2024, at 09:25, chenridong <chenridong@huawei.com> wrote:
>
>
>
> On 2024/10/15 14:55, Anshuman Khandual wrote:
>> On 10/14/24 16:59, Kirill A. Shutemov wrote:
>>> On Mon, Oct 14, 2024 at 03:23:36AM +0000, Chen Ridong wrote:
>>>> From: Chen Ridong <chenridong@huawei.com>
>>>>
>>>> A memleak was found as bellow:
>>>>
>>>> unreferenced object 0xffff8881010d2a80 (size 32):
>>>> comm "mkdir", pid 1559, jiffies 4294932666
>>>> hex dump (first 32 bytes):
>>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>>> 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 @...............
>>>> backtrace (crc 2e7ef6fa):
>>>> [<ffffffff81372754>] __kmalloc_node_noprof+0x394/0x470
>>>> [<ffffffff813024ab>] alloc_shrinker_info+0x7b/0x1a0
>>>> [<ffffffff813b526a>] mem_cgroup_css_online+0x11a/0x3b0
>>>> [<ffffffff81198dd9>] online_css+0x29/0xa0
>>>> [<ffffffff811a243d>] cgroup_apply_control_enable+0x20d/0x360
>>>> [<ffffffff811a5728>] cgroup_mkdir+0x168/0x5f0
>>>> [<ffffffff8148543e>] kernfs_iop_mkdir+0x5e/0x90
>>>> [<ffffffff813dbb24>] vfs_mkdir+0x144/0x220
>>>> [<ffffffff813e1c97>] do_mkdirat+0x87/0x130
>>>> [<ffffffff813e1de9>] __x64_sys_mkdir+0x49/0x70
>>>> [<ffffffff81f8c928>] do_syscall_64+0x68/0x140
>>>> [<ffffffff8200012f>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>>>
>>>> In the alloc_shrinker_info function, when shrinker_unit_alloc return
>>>> err, the info won't be freed. Just fix it.
>>>>
>>>> Fixes: 307bececcd12 ("mm: shrinker: add a secondary array for shrinker_info::{map, nr_deferred}")
>>>> Signed-off-by: Chen Ridong <chenridong@huawei.com>
>>>> ---
>>>> mm/shrinker.c | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/mm/shrinker.c b/mm/shrinker.c
>>>> index dc5d2a6fcfc4..92270413190d 100644
>>>> --- a/mm/shrinker.c
>>>> +++ b/mm/shrinker.c
>>>> @@ -97,6 +97,7 @@ int alloc_shrinker_info(struct mem_cgroup *memcg)
>>>> err:
>>>> mutex_unlock(&shrinker_mutex);
>>>> + kvfree(info);
>>>> free_shrinker_info(memcg);
>>>> return -ENOMEM;
>>>> }
>>>
>>> NAK. If in the future there going to one more error case after
>>> rcu_assign_pointer() we will end up with double free.
>>>
>>> This should be safer:
>>>
>>> diff --git a/mm/shrinker.c b/mm/shrinker.c
>>> index dc5d2a6fcfc4..763fd556bc7d 100644
>>> --- a/mm/shrinker.c
>>> +++ b/mm/shrinker.c
>>> @@ -87,8 +87,10 @@ int alloc_shrinker_info(struct mem_cgroup *memcg)
>>> if (!info)
>>> goto err;
>>> info->map_nr_max = shrinker_nr_max;
>>> - if (shrinker_unit_alloc(info, NULL, nid))
>>> + if (shrinker_unit_alloc(info, NULL, nid)) {
>>> + kvfree(info);
>>> goto err;
>>> + }
>>> rcu_assign_pointer(memcg->nodeinfo[nid]->shrinker_info, info);
>>> }
>>> mutex_unlock(&shrinker_mutex);
>> Agreed, this is what I mentioned earlier as well.
>> ------------------------------------------------------------------
>> I guess kvfree() should be called just after shrinker_unit_alloc()
>> fails but before calling into "goto err"
>> ------------------------------------------------------------------
>
> After discussion, it seems that v1 is acceptable.
> Hi, Muchun, do you have any other opinions?
I insist on my opinion, not mixing two different approaches
to do release resources.
Thanks.
>
> Best regards,
> Ridong
next prev parent reply other threads:[~2024-10-16 2:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-14 3:23 [PATCH v2] mm: shrinker: avoid memleak in alloc_shrinker_info Chen Ridong
2024-10-14 6:25 ` Muchun Song
2024-10-14 8:13 ` Anshuman Khandual
2024-10-14 8:43 ` Muchun Song
2024-10-14 9:04 ` chenridong
2024-10-14 9:20 ` Muchun Song
2024-10-14 9:38 ` chenridong
2024-10-16 12:13 ` Vlastimil Babka
2024-10-16 14:22 ` Muchun Song
2024-10-17 2:41 ` Qi Zheng
2024-10-14 11:29 ` Kirill A. Shutemov
2024-10-15 1:13 ` chenridong
2024-10-15 6:55 ` Anshuman Khandual
2024-10-16 1:25 ` chenridong
2024-10-16 2:21 ` Muchun Song [this message]
2024-10-16 10:16 ` Kirill A. Shutemov
2024-10-16 13:37 ` Muchun Song
2024-10-16 11:43 ` Vlastimil Babka
2024-10-16 14:08 ` Muchun Song
2024-10-16 17:02 ` Vlastimil Babka
2024-10-16 17:31 ` Roman Gushchin
2024-10-24 1:26 ` Chen Ridong
2024-10-24 9:08 ` Vlastimil Babka
2024-10-25 1:22 ` Chen Ridong
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=FD2AA126-5885-41C7-ACFD-85C764170B9E@linux.dev \
--to=muchun.song@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=chenridong@huawei.com \
--cc=david@fromorbit.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=roman.gushchin@linux.dev \
--cc=wangweiyang2@huawei.com \
--cc=zhengqi.arch@bytedance.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.