From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 11073363083 for ; Mon, 13 Jul 2026 06:27:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783924065; cv=none; b=P7JyRTnxcIMJYQLNdRC63T6O73GiQVMcZLtOJ6jt8SlIDmp8fN5XBc+IGrmdHn53Vdf1OHkjGpOAHjG6t61vAfhDrg4ZvPbcqgqBc53PusDIXzLrF/KmB+kVYN/ayQYUvNAKCWX/rUcM1dQBqFe2IGj6PCXfi5S/ebGmRv7ePVs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783924065; c=relaxed/simple; bh=U/ZjpSgYQZbcZJdFjobOIEANC6srZwvAyCb3zK/ZK1w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=TZbANL9jp3pMHQqK4kceaWOAHon+nYXzYiOwM79iwbNWWAQ7gEzTyzIZ+LRfczSV4nlwdAyQlEqi1l1VSzz7gPELjIXeGv3l/58LdItMedvG40J4hQnYXSn5u/QMv/wH5H2ITDjLpl0WKDe1Q54QqUwpMC9f635Uqg1c3+vxztw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aOHfHY1f; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aOHfHY1f" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DCE481F000E9; Mon, 13 Jul 2026 06:27:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783924064; bh=U/ZjpSgYQZbcZJdFjobOIEANC6srZwvAyCb3zK/ZK1w=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=aOHfHY1f5MF8mN3mAVQNx8AYlcBCK4m3TDXtoT73JZL+t93c5Kq7PjRq+8aYzY9B/ AAXhsChF2QdEVEVoqUf1reLfhBW0GR/udZUtxQXgZ8dtelVQ7NaD4mBNj8Pa+rbuq+ 1Q8v/DXokNs0hf+NSLQV0dXdCHMgX3lt9skvhktWAMuoWG9EaMoi2A+xmHU/rMe1G3 39CusoVClUL1HEOrioMRK3nrhh0mGBKX7drAWJM55KsGg+ZYhZB2Hc6C1DZYWTJZf2 px4D6pkrMiz1IZk2hGcblSDaenGINFnmoXfV3ZxJSjOZM4LVyMBO0JS6I7ccBmgL5m /oUkRjdyMGL/g== Message-ID: <40902df6-373c-4e87-9ec7-4e72f9f0efa2@kernel.org> Date: Mon, 13 Jul 2026 15:27:37 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/slub: fix kobject leak in sysfs_slab_add error path To: Hongling Zeng , 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 References: <20260713055829.127864-1-zenghongling@kylinos.cn> <6A548241.8080802@126.com> Content-Language: en-US From: Harry Yoo In-Reply-To: <6A548241.8080802@126.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------1vqnp8Gy807YDBQ4YweviOJT" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------1vqnp8Gy807YDBQ4YweviOJT Content-Type: multipart/mixed; boundary="------------DpHrR0LBb9GL03ozRue45Iha"; protected-headers="v1" From: Harry Yoo To: Hongling Zeng , 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 Message-ID: <40902df6-373c-4e87-9ec7-4e72f9f0efa2@kernel.org> Subject: Re: [PATCH] mm/slub: fix kobject leak in sysfs_slab_add error path References: <20260713055829.127864-1-zenghongling@kylinos.cn> <6A548241.8080802@126.com> In-Reply-To: <6A548241.8080802@126.com> --------------DpHrR0LBb9GL03ozRue45Iha Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/13/26 3:14 PM, Hongling Zeng wrote: >=20 > =E5=9C=A8 2026=E5=B9=B407=E6=9C=8813=E6=97=A5 14:07, Harry Yoo =E5=86=99= =E9=81=93: >> >> 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 clea= n >>> 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"). > =C2=A0 Thank you for the clarification. I see now that this was an inte= ntional > =C2=A0 design choice to allow cache creation to proceed even when sysfs= > =C2=A0 registration fails. >=20 >>> 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! >> > =C2=A0Good idea. Would a patch adding a comment like this be useful? > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 err =3D kobject_= init_and_add(&s->kobj, &slab_ktype, NULL, "%s", > name); > =C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* > =C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Note: Intentionall= y not calling kobject_put() on error. > =C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * > =C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * The kobject releas= e callback (slab_kmem_cache_release) would > =C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * free the entire km= em_cache structure. However, sysfs > =C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * registration failu= res are treated as non-fatal - the cache > =C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * continues to be us= ed. See commit 2420baa8e046 ("mm/slab: Allow > =C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * cache creation to = proceed even if sysfs registration fails"). > =C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 */ 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")" > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (err) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 goto out; > =20 --=20 Cheers, Harry / Hyeonggon --------------DpHrR0LBb9GL03ozRue45Iha-- --------------1vqnp8Gy807YDBQ4YweviOJT Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQQ1ub6gR5ogjaKRmOGXBN6rc5S1gUCalSFWQAKCRCGXBN6rc5S 1vfwAQD/EzTBbAjUAGLpOeDDHKrwVLP/t4Ujfw7f6yBtt+HqNAD/a0CjyLan7HbP vn/n4WR0uDMGarH+OMGpXiPnAjM0ag8= =m9ef -----END PGP SIGNATURE----- --------------1vqnp8Gy807YDBQ4YweviOJT--