From: Harry Yoo <harry@kernel.org>
To: Hongling Zeng <zhongling0719@126.com>,
vbabka@kernel.org, akpm@linux-foundation.org, hao.li@linux.dev,
cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev,
vdavydov.dev@gmail.com, davej@fedoraproject.org
Cc: Hongling Zeng <zenghongling@kylinos.cn>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/slub: fix kobject leak in sysfs_slab_add error path
Date: Mon, 13 Jul 2026 15:27:37 +0900 [thread overview]
Message-ID: <40902df6-373c-4e87-9ec7-4e72f9f0efa2@kernel.org> (raw)
In-Reply-To: <6A548241.8080802@126.com>
[-- Attachment #1.1: Type: text/plain, Size: 2411 bytes --]
On 7/13/26 3:14 PM, Hongling Zeng wrote:
>
> 在 2026年07月13日 14:07, Harry Yoo 写道:
>>
>> On 7/13/26 2:58 PM, Hongling Zeng wrote:
>>> When kobject_init_and_add() fails in sysfs_slab_add(), the kobject
>>> is not properly cleaned up, causing a memory leak.
>>>
>>> According to the kobject API documentation, when kobject_init_and_add()
>>> returns an error, the caller must call kobject_put() to properly clean
>>> up the memory associated with the object. The current code only frees
>>> the 'name' string but forgets to release the kobject reference.
>> This was intentional, please see commit 2420baa8e046 ("mm/slab: Allow
>> cache creation to proceed even if sysfs registration fails").
> Thank you for the clarification. I see now that this was an intentional
> design choice to allow cache creation to proceed even when sysfs
> registration fails.
>
>>> Fix this by calling kobject_put() before jumping to the error label.
>>>
>>> Fixes: 54b6a731025f ("slub: fix leak of 'name' in sysfs_slab_add")
>>> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
>>> ---
>>
>> Uh, there was a similar attempt recently...
>>
>> https://lore.kernel.org/linux-mm/
>> gimwkjjpvwu2sg5625b3eeatw2vhv7rs6enm3vepdduhcefbf5@xen5iec7sn3z
>>
>> Sounds like we need a comment saying it is intentional!
>>
> Good idea. Would a patch adding a comment like this be useful?
>
> err = kobject_init_and_add(&s->kobj, &slab_ktype, NULL, "%s",
> name);
> + /*
> + * Note: Intentionally not calling kobject_put() on error.
> + *
> + * The kobject release callback (slab_kmem_cache_release) would
> + * free the entire kmem_cache structure. However, sysfs
> + * registration failures are treated as non-fatal - the cache
> + * continues to be used. See commit 2420baa8e046 ("mm/slab: Allow
> + * cache creation to proceed even if sysfs registration fails").
> + */
Could we make it bit more concise please?
Something like
"Intentionally skip kobject_put(). See commit 2420baa8e046 ("mm/slab:
Allow cache creation to proceed even if sysfs registration fails")"
> if (err)
> goto out;
>
--
Cheers,
Harry / Hyeonggon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-07-13 6:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 5:58 [PATCH] mm/slub: fix kobject leak in sysfs_slab_add error path Hongling Zeng
2026-07-13 6:07 ` Harry Yoo
2026-07-13 6:14 ` Hongling Zeng
2026-07-13 6:27 ` Harry Yoo [this message]
2026-07-13 7:09 ` 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=40902df6-373c-4e87-9ec7-4e72f9f0efa2@kernel.org \
--to=harry@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=davej@fedoraproject.org \
--cc=hao.li@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@kernel.org \
--cc=vdavydov.dev@gmail.com \
--cc=zenghongling@kylinos.cn \
--cc=zhongling0719@126.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