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 8A8BA1A0B0E for ; Sun, 5 Jul 2026 04:46:24 +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=1783226785; cv=none; b=nYeblteurkSJrG/VFG0pzJBPN/BsoohIkcQKMGluS+oqk8zn/9b5UEXjbzoTi4OQB1TRcEXZvZ932EyFgXjry9xcU3yRRL7KSq3Q+Dro52qnuaHSKPE6NNSGur97J0QOF2RZHcswkEjwPM1MDzHhKGH3k7v9CkzAPezJrf3k0lE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783226785; c=relaxed/simple; bh=Kk9UMQgduFXKfC5Q0FWlpkvwry84T3rCEXLYuivbZ/E=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fopQWFp1AaLflh8n35GNVz/ra/nRMT2KfXZ+gGGLq3RbCssWcB43AKb3QnYlKS7KFB4QS6+Uj1US+UFLZ/TZBkiEooDcEfc4Y4B1F5OALARc43KGLiB5+Je/JlGFJ8MGJlMcsmNvt/tVG7erLKa6MMh+jJbwafTYPFbA9Xe4C7U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ldarkZ3e; 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="ldarkZ3e" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 177E61F000E9; Sun, 5 Jul 2026 04:46:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783226784; bh=yS8tgMFHK16gSd7DdvCSlq4Fkcx4ZMA8N73FiBRXdhw=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=ldarkZ3egtjcsy6bcatiw7N/TsfCSvt6dAg7K6aQxhaxDhMrrfewm+k2QCypCbwHq KqnCF0r0BFVYoaGJor/NsspNjoK1l4QoH1oq7s6TVQh8ZiDgAFOEgEUYefr/8+hc0i Bleyk4L9gc6QhQ339R/XLxlu7rbEwUes6EFUFpIGluk92blmo0BuX6lOyX6GdjbIgI wSVkHIv2B5bfy12drDL1mXZbJFu5Soo8x+jgLc1bfwUTsEH/HCF1NwJ9tbv2X/wfQT Zi53YMSC6zAMBl1u3nSnO7gw+8pgaYIYcn999oEnAuMWIx9YAZpfDhT559zCvDR5Tf 7+DbK450rzEqw== Message-ID: <7f211fa8-e2d8-4878-a8db-fd275d4c6821@kernel.org> Date: Sun, 5 Jul 2026 13:46:17 +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 lost local objects when bulk remote free batch fills To: hu.shengming@zte.com.cn, vbabka@kernel.org, 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: <20260704160450302fnznThT3hBeBiwlhE-oGv@zte.com.cn> Content-Language: en-US From: Harry Yoo In-Reply-To: <20260704160450302fnznThT3hBeBiwlhE-oGv@zte.com.cn> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------B0QdMbL9ogUbc1uFToe2mPr9" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------B0QdMbL9ogUbc1uFToe2mPr9 Content-Type: multipart/mixed; boundary="------------XUrLp9QppIPe1C4Gxvb0MSiE"; protected-headers="v1" From: Harry Yoo To: hu.shengming@zte.com.cn, vbabka@kernel.org, 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: <7f211fa8-e2d8-4878-a8db-fd275d4c6821@kernel.org> Subject: Re: [PATCH] mm/slub: fix lost local objects when bulk remote free batch fills References: <20260704160450302fnznThT3hBeBiwlhE-oGv@zte.com.cn> In-Reply-To: <20260704160450302fnznThT3hBeBiwlhE-oGv@zte.com.cn> --------------XUrLp9QppIPe1C4Gxvb0MSiE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Shengming, On 7/4/26 5:04 PM, hu.shengming@zte.com.cn wrote: > From: Shengming Hu >=20 > 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 entries= > have already been compacted out of p[] via tail swaps while local objec= ts > remain, the flush_remote path returns early since `i < size` no longer > holds. The leftover local objects are then neither cached in the sheaf = > nor returned to the slab freelist, causing a memory leak. Ouch. Interestingly, we fixed a similar memory leak in free_to_pcs_bulk() during the v6.18 cycle; commit cbcff934fa7d ("mm/slub: fix memory leak in free_to_pcs_bulk()"). Hmm, I feel is a signal that the control flow is quite complicated and worth revisiting if we could simplify the logic there. I'm not saying we should do that to fix the bug, just mentioning. > 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. I can see that could indeed happen. Interesting. How has it been undiscovered until today? Well, for this to trigger, at least PCS_BATCH_MAX (hardcoded to 32) objects in the sheaf should be from remote nodes. Looking at kmem_cache_free_bulk() 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 capacity is (at least for now) purely based on the object size (with user-requested capacity as a minimum) Only maple_node cache (out of four users) has sheaf_capacity >=3D PCS_BATCH_MAX. However, for this to trigger in maple_node cache, ALL objects in the sheaf should have been from remote nodes. And that means there is no local object to leak :) So, although the logic has a leak, you cannot trigger this in reality yet= =2E > Replace the goto-based flush with an in-place free of full remote batch= es > during the scan, then resume processing the compacted array. All local > objects now go through the normal fast path, and the tail path only > handles any leftover partial remote batch. The redundant next_remote_ba= tch > jump label is removed as well. >=20 > Fixes: <989b09b73978>("slab: skip percpu sheaves for remote object free= ing") > Signed-off-by: Shengming Hu > --- --=20 Cheers, Harry / Hyeonggon --------------XUrLp9QppIPe1C4Gxvb0MSiE-- --------------B0QdMbL9ogUbc1uFToe2mPr9 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQQ1ub6gR5ogjaKRmOGXBN6rc5S1gUCaknhmQAKCRCGXBN6rc5S 1oiJAP9yRGJ0XdV2ZAHxJ346MUIWLyf26AnizXwKcn6sT5UQ8wEAhFVeSyaKEMOk YeYpdg+WF68xx/8IogS8hl0Dg2+olgw= =FnEW -----END PGP SIGNATURE----- --------------B0QdMbL9ogUbc1uFToe2mPr9--