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 8BA373C76BC for ; Mon, 20 Jul 2026 10:43:08 +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=1784544192; cv=none; b=Ex8fGw+88l6Gx5/KJmGZrGUrXOXNNgST8tm1NlTnj8gygAsG5yU4REbdZ7HgtbCf143MraIMOeJbog5+qBZ8AI2cWg6yQN8k4gtSyAQdq0gR49SNHG/jmhAYv83RnQab/yR9q3QVeBPeXjZnqVlaEIlydmYRLZQ7t68ULjthXoY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784544192; c=relaxed/simple; bh=OBsy+tVX941ooou07UO4wORU8Z5WlMygXspARqEVhK8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=L7Zejqgg81makzKl9fN0/EjAtG8ud5Kl1slCZNLGVrpWmQ20nPqZzTrA2lB4Z/uXsFr2w9oXZ+2O4RDPvFACSBs3kLQzTOpSKI3kF21wHU18AbuGLdmps9ES6MtdA5oC6BFHiH1a3CKLbgsLorth5nYcmbuaCNzyGpjNtptvBfs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=m2v5jzul; 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="m2v5jzul" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F67E1F00A3A; Mon, 20 Jul 2026 10:43:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784544188; bh=nsfmWiegW0OILsLVKeO/049ziGI5iaH5BD/NGSwJfpk=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=m2v5jzulxqgbEghkgipyDUC1HMOf6eV25n5F6Dlura3AEtvoMzfE+zJyKV45ZngFh T0mRGUmpa/kqfc8YYch9sHjjWa9wWUQZLPmGxbx0If3rvWmT6PjXPxnHSQ5TJGKpg8 mMQ3ZSNfBIJbMR1TC34819lwe+93jfYvdc4jBZ7NZXl+CWZT7EjKZnvbYmbzQHwgnQ yw2sC1ILxLib5OkxgvheeHsgsBOTVh3+hL49G4F7sZK9rMTmiIHn1tx44l6WW0tw6r r/tSDsTa8DgdUeK4LFKIZO+U5/jAS2wZ+k86DbYspwy+7mRg6+J7dFsUlbvnCNYyDh aiE4NtaOLVEZQ== Message-ID: <33a1cb67-8d23-4b51-b4d8-9e95e8de00c7@kernel.org> Date: Mon, 20 Jul 2026 19:43:04 +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: prevent pfmemalloc objects from entering the barn To: hu.shengming@zte.com.cn, hao.li@linux.dev Cc: vbabka@kernel.org, akpm@linux-foundation.org, 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: <20260720164108387NvWvBxxTPdY-K3EVodBZZ@zte.com.cn> Content-Language: en-US From: Harry Yoo In-Reply-To: <20260720164108387NvWvBxxTPdY-K3EVodBZZ@zte.com.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/20/26 5:41 PM, hu.shengming@zte.com.cn wrote: > Hao wrote: >> On Sun, Jul 19, 2026 at 11:37:01AM +0800, hu.shengming@zte.com.cn wrot= e: >>> From: Shengming Hu >>> >>> kmem_cache_return_sheaf() may refill a partially consumed sheaf befor= e >>> placing it in the barn. Without an explicit restriction, this refill = may >>> draw objects from pfmemalloc slabs and consume emergency reserves. >>> >>> Add __GFP_NOMEMALLOC so returned sheaves are refilled only from norma= l >>> memory. If that fails, flush and free the sheaf instead. >>> >>> Signed-off-by: Shengming Hu >>> --- >>> mm/slub.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/mm/slub.c b/mm/slub.c >>> index 53b4976d3831..34f17ecbde87 100644 >>> --- a/mm/slub.c >>> +++ b/mm/slub.c >>> @@ -5123,7 +5123,7 @@ void kmem_cache_return_sheaf(struct kmem_cache = *s, gfp_t gfp, >>> * simply flush and free it. >>> */ >>> if (!barn || data_race(barn->nr_full) >=3D MAX_FULL_SHEAVES || >>> - refill_sheaf(s, sheaf, gfp)) { >>> + refill_sheaf(s, sheaf, gfp | __GFP_NOMEMALLOC)) { >> >> maybe we can add __GFP_NOWARN as this is just an refilling attempt? >> refilling failure could be acceptable. Adding __GFP_NOMEMALLOC | __GFP_NOWARN makes sense to me. Analogous to __pcs_replace_empty_main(). We don't really put pfmemalloc sheaves back to the barn but as you pointed out kmem_cache_return_sheaf() could fill the non-pfmemalloc sheaf with objects from pfmemalloc slabs. > Thanks for the review! >=20 > Good suggestion. Since refilling the sheaf is only a best-effort attemp= t > and failure is acceptable here, adding __GFP_NOWARN makes sense. > > After taking another look, maybe we should also clear __GFP_NOFAIL if > it is present in the caller-provided GFP flags? Otherwise, the allocati= on > could retry indefinitely, which may not be appropriate for this optiona= l > refill path. Hmm, you might argue that it's not worth trying to refill the whole sheaf w/ __GFP_NOFAIL in refill_sheaf() if e.g.) that end up reclaiming more than one page under high memory pressure. (Just like how we clear __GFP_NOFAIL when allocating high-order sheaves). But that should not be part of this patch at least. --=20 Cheers, Harry / Hyeonggon