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 6989844B67F for ; Wed, 8 Jul 2026 14:01:07 +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=1783519268; cv=none; b=BcRc6Ciej6PjI7Mc2Did18k6m1JmufyaXySgqQMdcxiSGSUcwqZQCBM2XFU0qH0cr93V3Tko0u9YXa5NE2kt9cWwo7oyj5oJg9uirpmogICnoqXD0f4QJok32ToheIPsaejPzr9mIHSNs2GNPB8JuLmRpB2t5hrcxcPQ36whT50= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783519268; c=relaxed/simple; bh=by5FVTZeT81gqTdJHaVY8rXdk/bMy9sfXum6nr/IgnM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=seh4ydaKS++0sQQjvw5KuzIxk8BFvkM50AfTxmFfY3ny0ZE8c1gN4tfI9iZ30A25TAgNSRFfOpuRzgIb07rYcIZw3/P5eBEj1y71Qo49WT6VF/m1/z8G9E86Tef3LGW9k/rt4OJhwIPFQhcNSVAyxocBzvlUlGZKxaCHLQQVocw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hlMlCC2k; 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="hlMlCC2k" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 36DC91F00A3A; Wed, 8 Jul 2026 14:01:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783519267; bh=ZWBeYBKTsPxmSmrWR5dD6tT/sFVgb0W2FXc/WHMVd3o=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=hlMlCC2krrSFfA0KjxNyo3KbctkEX2rJPS6YVpogfSe15ml6rs6a3COh/0LmJryoX YlGBO1jbfzs0dvAEOVNjMlSeiLzCt1JWQJ7jIJ6CGsNInl3uK17PLnbE5JI9PIJCyi bYyYNXmMYMtOdEL3+t+A+uqHIwN+9YBsIq4jfSk2POFwscKdkCwH/X9KIuLSSfW8ld RaD4bqqydV0UD6RsL6FoqJdoiVRqFmk1unXjPSR46mJqLUbTy9zRb65NmD6GdvRRGf pGl6vjrMcQt4AyFoGxsZBXqxCRVywRWHDcafzcJ6OQolNE0zXwWWTz3g6s6T5RQME0 h1t4SvL7ErnOw== Message-ID: Date: Wed, 8 Jul 2026 23:00:59 +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 v2] mm/slub: fix lost local objects when bulk remote free batch fills To: "Vlastimil Babka (SUSE)" , hu.shengming@zte.com.cn, akpm@linux-foundation.org Cc: hao.li@linux.dev, cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, zhang.run@zte.com.cn, cai.qu@zte.com.cn References: <202607062139095043SOsLi6TIf403tcjPf8fm@zte.com.cn> <84c4c2bf-397e-461c-b898-482d1a49f40b@kernel.org> Content-Language: en-US From: Harry Yoo In-Reply-To: <84c4c2bf-397e-461c-b898-482d1a49f40b@kernel.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------a7AZcdOAk08A059gQIFz2y9h" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------a7AZcdOAk08A059gQIFz2y9h Content-Type: multipart/mixed; boundary="------------0pyQRp0tdhi5apzn07P0glTF"; protected-headers="v1" From: Harry Yoo To: "Vlastimil Babka (SUSE)" , hu.shengming@zte.com.cn, akpm@linux-foundation.org Cc: hao.li@linux.dev, cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, zhang.run@zte.com.cn, cai.qu@zte.com.cn Message-ID: Subject: Re: [PATCH v2] mm/slub: fix lost local objects when bulk remote free batch fills References: <202607062139095043SOsLi6TIf403tcjPf8fm@zte.com.cn> <84c4c2bf-397e-461c-b898-482d1a49f40b@kernel.org> In-Reply-To: <84c4c2bf-397e-461c-b898-482d1a49f40b@kernel.org> --------------0pyQRp0tdhi5apzn07P0glTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/7/26 6:27 PM, Vlastimil Babka (SUSE) wrote: > On 7/6/26 15:39, hu.shengming@zte.com.cn wrote: >> From: Shengming Hu >> >> In free_to_pcs_bulk(), when remote_objects[] fills to PCS_BATCH_MAX, >> the code jumps to flush_remote to free the batch. If all remote entrie= s >> have already been compacted out of p[] via tail swaps while local obje= cts >> remain, the flush_remote path returns early since `i < size` no longer= >> holds. The leftover local objects are then neither cached in the sheaf= =20 >> nor returned to the slab freelist, causing a memory leak. >> >> For illustration: >> size =3D 64, local objects at p[0..31], remote objects at p[32..63] >> After scanning all remotes: i =3D 32, size =3D 32 >> p[0..31] local objects are dropped. >> >> Harry pointed out that, although the logic contains a real leak, it do= es >> not appear to be triggerable with the current in-tree users. To hit th= is >> path, at least PCS_BATCH_MAX objects, currently hardcoded to 32, need = to >> be collected in remote_objects[]. Looking at current kmem_cache_free_b= ulk() >> users: >> >> * maple_node has sheaf_capacity =3D 32 >> * skbuff_head_cache has sheaf_capacity =3D 28 >> * panthor and msm drivers have sheaf_capacity =3D 4 >> >> The sheaf capacity is, at least for now, derived purely from the objec= t >> size, with the user-requested capacity used as a minimum. Therefore, a= mong >> the current users, only maple_node has a sheaf_capacity large enough t= o >> reach PCS_BATCH_MAX. >> >> However, for the bug to trigger in maple_node, all objects in the shea= f >> would have to be from remote nodes. In that case, there would be no lo= cal >> objects left to leak. So this issue was found by code review rather th= an >> from a runtime report, and it does not seem to be triggerable by curre= nt >> users. >> >> Still, the bug could become reachable with future users, a different s= heaf >> capacity, or a change to PCS_BATCH_MAX. Fix the logic by freeing a ful= l >> remote batch in place during the scan and then continuing to process t= he >> compacted array. This keeps all local objects on the normal fast path,= >> while the tail path only handles any leftover partial remote batch. Th= e >> redundant next_remote_batch jump label is removed as well. >> >> Fixes: <989b09b73978>("slab: skip percpu sheaves for remote object fre= eing") >=20 > Removed the < > >=20 >> Signed-off-by: Shengming Hu >=20 > Thanks! I added cc: stable anyway so we avoid unexpected surprises in c= ase > something else is backported there that exposes the bug. And the fix is= > small enough. Ack. > Merged to slab/for-next-fixes >=20 >> --- Reviewed-by: Harry Yoo (Oracle) Thanks! --=20 Cheers, Harry / Hyeonggon --------------0pyQRp0tdhi5apzn07P0glTF-- --------------a7AZcdOAk08A059gQIFz2y9h Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQQ1ub6gR5ogjaKRmOGXBN6rc5S1gUCak5YHAAKCRCGXBN6rc5S 1sWKAQC+KhWT6wvchRiroFUB/oFj9EbbMA/6FCabhMvsQqNKBgEAqFTLaSdGYUyy k0Z2DDN460S7c7J762T9o7WNYzHL/AQ= =vh99 -----END PGP SIGNATURE----- --------------a7AZcdOAk08A059gQIFz2y9h--