From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.126.com (m16.mail.126.com [220.197.31.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DCBB314E2F2 for ; Mon, 13 Jul 2026 06:15:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.8 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783923350; cv=none; b=DaKUnrxNff5/mpJuZ89acrrOS9QmIcleoq6dG5WhcLxi/7Vl7uYA//jiofgIilVrFQHpBG8I7NBvXcaZ7qcnYuHk3SS1hZu7RYiHX4QrDwyij7YG/Oo93gC8km9/JrZlFbBfcN5KqE5PLxmODnMJNluzRZ/JylyATpIEdnLmG40= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783923350; c=relaxed/simple; bh=/P4gSJEvN0hxpmWOZBY7yjiJleS2fBdKeyCoyAsdpbI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=CSXOhUEiyApY4PBQtXEFymn0PjIvuq++7T9YPybzomJ52V/9u4CDmALpSsrQ1LF6ZXBi0z1GB6YgYi7i4Ex+jbmsJ40IkmoJUhboHnTRXjB3Rz1NRCyFqOt5TWHznV4S6tyWHDucEbyr1kHNxpMSlvSDKHjtpbhHj/SHCN3s2I8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=126.com; spf=pass smtp.mailfrom=126.com; dkim=pass (1024-bit key) header.d=126.com header.i=@126.com header.b=JURd2NP0; arc=none smtp.client-ip=220.197.31.8 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=126.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=126.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=126.com header.i=@126.com header.b="JURd2NP0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; bh=vuKe8obP3PPRho0ooKW9/QhnrwO8R0l3sZh6B7h7Ymo=; b=JURd2NP03aYq1nnqLajFaCGjFGs5JVBTC81Hd1Peh1Qcc4cTT4YEOIu5wrRlSr EfJpBQfUTTzxa2g33/wGyBzRbEwWb+XKGvsP0rSwm8l0ToXoSn5eLcodbfwODOmp RcLpg8cv7RmabiK0CLumdMYBsizUUQG1XWIW/zw7Btbdw= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g0-1 (Coremail) with SMTP id _____wC3b5NUglRq33tmDA--.15770S2; Mon, 13 Jul 2026 14:14:45 +0800 (CST) Message-ID: <6A548241.8080802@126.com> Date: Mon, 13 Jul 2026 14:14:25 +0800 From: Hongling Zeng User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 To: Harry Yoo , 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 , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/slub: fix kobject leak in sysfs_slab_add error path References: <20260713055829.127864-1-zenghongling@kylinos.cn> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wC3b5NUglRq33tmDA--.15770S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxJr4xZrW8try3Wr1fZrWUJwb_yoW8Aw4Dpr 9xXa47KFZrGa1xKwsrX3W8W34ru395JFs8GF4Fgw40krn3uF18tr4xKF9rZFyDCr48Ga17 Xa12yr90gF15CaUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07j4Hq7UUUUU= X-CM-SenderInfo: x2kr0wpolqwiqxrzqiyswou0bp/xtbBoRVlNmpUglXHBQAA3M 在 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 >> --- > > 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"). + */ if (err) goto out; Thanks!