Add a comment to clarify why we don't call kobject_put() when
kobject_init_and_add() fails in sysfs_slab_add().

Per commit 2420baa8e046 ("mm/slab: Allow cache creation to proceed
even if sysfs registration fails"), sysfs failures are treated as
non-fatal and the cache continues to be used. Calling kobject_put()
would trigger slab_kmem_cache_release() which frees the entire
cache structure, so we intentionally skip it.

Suggested-by: Harry Yoo <harry@kernel.org>
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
 Change in v1:
 -Correct the email
---
 mm/slub.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/mm/slub.c b/mm/slub.c
index 9ec774dc7009..edc822d7d9ea 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -9690,6 +9690,11 @@ static int sysfs_slab_add(struct kmem_cache *s)
 
 	s->kobj.kset = kset;
 	err = kobject_init_and_add(&s->kobj, &slab_ktype, NULL, "%s", name);
+	/*
+	 * Intentionally skip kobject_put(). See commit 2420baa8e046
+	 * ("mm/slab: Allow cache creation to proceed even if sysfs
+	 * registration fails")
+	 */
 	if (err)
 		goto out;
 
-- 
2.25.1

On 7/13/26 09:00, Hongling Zeng wrote:
> Add a comment to clarify why we don't call kobject_put() when
> kobject_init_and_add() fails in sysfs_slab_add().
> 
> Per commit 2420baa8e046 ("mm/slab: Allow cache creation to proceed
> even if sysfs registration fails"), sysfs failures are treated as
> non-fatal and the cache continues to be used. Calling kobject_put()
> would trigger slab_kmem_cache_release() which frees the entire
> cache structure, so we intentionally skip it.
> 
> Suggested-by: Harry Yoo <harry@kernel.org>
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>

Thanks, added to slab/for-next

> ---
>  Change in v1:
>  -Correct the email
> ---
>  mm/slub.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 9ec774dc7009..edc822d7d9ea 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -9690,6 +9690,11 @@ static int sysfs_slab_add(struct kmem_cache *s)
>  
>  	s->kobj.kset = kset;
>  	err = kobject_init_and_add(&s->kobj, &slab_ktype, NULL, "%s", name);
> +	/*
> +	 * Intentionally skip kobject_put(). See commit 2420baa8e046
> +	 * ("mm/slab: Allow cache creation to proceed even if sysfs
> +	 * registration fails")
> +	 */
>  	if (err)
>  		goto out;
>

On 7/13/26 4:00 PM, Hongling Zeng wrote:
> Add a comment to clarify why we don't call kobject_put() when
> kobject_init_and_add() fails in sysfs_slab_add().
> 
> Per commit 2420baa8e046 ("mm/slab: Allow cache creation to proceed
> even if sysfs registration fails"), sysfs failures are treated as
> non-fatal and the cache continues to be used. Calling kobject_put()
> would trigger slab_kmem_cache_release() which frees the entire
> cache structure, so we intentionally skip it.
> 
> Suggested-by: Harry Yoo <harry@kernel.org>
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
> ---
>
>  Change in v1:
>  -Correct the email

Hmm, the email "Hyeonggon Kim <pictureone@kakao.com>" came out of
nowhere. Could you please explain why this happened?

> ---
>  mm/slub.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 9ec774dc7009..edc822d7d9ea 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -9690,6 +9690,11 @@ static int sysfs_slab_add(struct kmem_cache *s)
>  
>  	s->kobj.kset = kset;
>  	err = kobject_init_and_add(&s->kobj, &slab_ktype, NULL, "%s", name);
> +	/*
> +	 * 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

在 2026年07月13日 15:26, Harry Yoo 写道:
> On 7/13/26 4:00 PM, Hongling Zeng wrote:
>> Add a comment to clarify why we don't call kobject_put() when
>> kobject_init_and_add() fails in sysfs_slab_add().
>>
>> Per commit 2420baa8e046 ("mm/slab: Allow cache creation to proceed
>> even if sysfs registration fails"), sysfs failures are treated as
>> non-fatal and the cache continues to be used. Calling kobject_put()
>> would trigger slab_kmem_cache_release() which frees the entire
>> cache structure, so we intentionally skip it.
>>
>> Suggested-by: Harry Yoo <harry@kernel.org>
>> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
>> ---
>>
>>   Change in v1:
>>   -Correct the email
> Hmm, the email "Hyeonggon Kim <pictureone@kakao.com>" came out of
> nowhere. Could you please explain why this happened?
   My apologies for the confusion.

   I incorrectly retrieved your email from a signature search ：）
>> ---
>>   mm/slub.c | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/mm/slub.c b/mm/slub.c
>> index 9ec774dc7009..edc822d7d9ea 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -9690,6 +9690,11 @@ static int sysfs_slab_add(struct kmem_cache *s)
>>   
>>   	s->kobj.kset = kset;
>>   	err = kobject_init_and_add(&s->kobj, &slab_ktype, NULL, "%s", name);
>> +	/*
>> +	 * Intentionally skip kobject_put(). See commit 2420baa8e046
>> +	 * ("mm/slab: Allow cache creation to proceed even if sysfs
>> +	 * registration fails")
>> +	 */
>>   	if (err)
>>   		goto out;

On 7/13/26 4:45 PM, Hongling Zeng wrote:
> 在 2026年07月13日 15:26, Harry Yoo 写道:
>> On 7/13/26 4:00 PM, Hongling Zeng wrote:
>>> Add a comment to clarify why we don't call kobject_put() when
>>> kobject_init_and_add() fails in sysfs_slab_add().
>>>
>>> Per commit 2420baa8e046 ("mm/slab: Allow cache creation to proceed
>>> even if sysfs registration fails"), sysfs failures are treated as
>>> non-fatal and the cache continues to be used. Calling kobject_put()
>>> would trigger slab_kmem_cache_release() which frees the entire
>>> cache structure, so we intentionally skip it.
>>>
>>> Suggested-by: Harry Yoo <harry@kernel.org>
>>> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
>>> ---

FWIW, the patch looks fine to me, so:
Acked-by: Harry Yoo (Oracle) <harry@kernel.org>

>>>   Change in v1:
>>>   -Correct the email
>>
>> Hmm, the email "Hyeonggon Kim <pictureone@kakao.com>" came out of
>> nowhere. Could you please explain why this happened?
>   My apologies for the confusion.
> 
>   I incorrectly retrieved your email from a signature search ：）

You mean retrieved from your local address book?

-- 
Cheers,
Harry / Hyeonggon