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 812FD39EF16 for ; Tue, 21 Jul 2026 14:27:50 +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=1784644072; cv=none; b=nD9uJLoEciyRBP8PHhC+ak86wzgYY0p+xZTAwv1nRmJzDADOKB2ZTgll1lyXtCHNbHyCjbYqKOkl3mwelJvKu+HfiptmeOEdFZMq1y/1oFlr6+mkNrVU33bLaA3p+c0XJsYgS7UxscbUhf0v7EbadExwcNn1IbQtuGtFC771HkE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784644072; c=relaxed/simple; bh=/hbBadusRREWVUqTtdhXuQ+80Xw3Ko8XAXx4ac8NSeM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=AHwIsiq2Y+yAGcdy1GENdI3MuPIxBVuWWPfOCcY8FiLSCe+wDNe7ceJ+xcPdQD2R4bgFGUPSZyy5ZUE3YjBzSBV0Tqk27vOwv/shTohHO89HqMiAc7Ys9/E76fyzDacSHJ29md2Vw6xrvpmnY6UpbT3uev56bOpo0dzHRIwDgSc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fJzDy6Ig; 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="fJzDy6Ig" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E73BE1F000E9; Tue, 21 Jul 2026 14:27:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784644070; bh=/hbBadusRREWVUqTtdhXuQ+80Xw3Ko8XAXx4ac8NSeM=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=fJzDy6IgiEZtb7HFq1XLK0UmH47YMcm7bZ9lqLlVBZuDHTWD2xm+6k1HR9qjc7REv w+dJnrMqxyxXemFx74Y1FkXKEeGb9jjP2npUg1Hyh3cXr217iizQcEGP9wfEs5B5LP JoX+JtAB0/dnOvq93/lws2jxLYWOAalFUo7fSXAllM7l8DHbrYHWtGFNpyVC9ZL52u OMxPw+xY1x8iYA8lWhCDyb0YQH7oSonpA4MGFhh/xA9cu92tguJz3r5rPEarLnwsq9 gi7XPi8wMIEIn10Zx8jb6WBk+3eAeNda0sOJ56BsqZJHS8c/rcrsAjHR7UGoHIpnNN OhRiMhevVqy6A== Message-ID: <85ddd27a-ade6-4f27-80ab-cb91caa4e171@kernel.org> Date: Tue, 21 Jul 2026 23:27:39 +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 v3] mm/slub: prevent pfmemalloc objects from entering the barn To: hu.shengming@zte.com.cn, vbabka@kernel.org Cc: akpm@linux-foundation.org, 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: <20260721171753509I9L8xNy2kiOGQFKloTnrG@zte.com.cn> Content-Language: en-US From: Harry Yoo In-Reply-To: <20260721171753509I9L8xNy2kiOGQFKloTnrG@zte.com.cn> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------6NUTL4gdv4n2o3m1W8I1bwuM" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------6NUTL4gdv4n2o3m1W8I1bwuM Content-Type: multipart/mixed; boundary="------------jgzpjNmUZ6ZOyMcxhrm0Gj91"; protected-headers="v1" From: Harry Yoo To: hu.shengming@zte.com.cn, vbabka@kernel.org Cc: akpm@linux-foundation.org, 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: <85ddd27a-ade6-4f27-80ab-cb91caa4e171@kernel.org> Subject: Re: [PATCH v3] mm/slub: prevent pfmemalloc objects from entering the barn References: <20260721171753509I9L8xNy2kiOGQFKloTnrG@zte.com.cn> In-Reply-To: <20260721171753509I9L8xNy2kiOGQFKloTnrG@zte.com.cn> --------------jgzpjNmUZ6ZOyMcxhrm0Gj91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/21/26 6:17 PM, hu.shengming@zte.com.cn wrote: > Vlastimil wrote: >> On 7/21/26 02:45, hu.shengming@zte.com.cn wrote: >>> 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 that returned sheaves are refilled only from >>> non-pfmemalloc slabs. Also add __GFP_NOWARN, as suggested by Hao Li, >>> because this refill is a best-effort attempt and failure is acceptabl= e. >>> If the refill fails, flush and free the sheaf instead. >>> >>> Fixes: 3c1ea5c5019f ("slab: sheaf prefilling for guaranteed allocatio= ns") >>> Cc: stable@vger.kernel.org >>> Signed-off-by: Shengming Hu >> >> Ah so per sashiko [1] we should consider adding also a __GFP_NORETRY t= o >> avoid an OOM kill. Seems reasonable that an API for returning memory s= hould >> not cause an OOM kill... it's unusual enough that it takes gfp flags Ideally the caller should not specify gfp flags that could invoke OOMs.... but even GFP_KERNEL for non-costly order could invoke them. > but I > thought defaulting to GFP_NOWAIT would be an unnecessary limitation. I think it's reasonable to drop gfp parameter and default to GFP_NOWAIT rather than relying on the callers to avoid OOMs or implicitly overriding the behavior. It wouldn't be too limiting given that it's for returning memory (!) and other free APIs don't take GFP flags and assume GFP_NOWAIT e.g.) when allocating a new sheaf. > I can add __GFP_NORETRY locally if others agree. > >> [1] >> https://sashiko.dev/#/patchset/20260721084522552ZPa16p1SRj3PYat3sqxuN%= 40zte.com.cn >=20 > Agreed, adding __GFP_NORETRY seems reasonable, since this best-effort > refill should not trigger the OOM killer. >=20 > However, I wonder whether the same scope consideration that Harry raise= d > for __GFP_NOFAIL also applies here, and whether __GFP_NORETRY should be= > discussed separately rather than folded into this pfmemalloc fix. Agreed that this is an independent issue. > The earlier discussion is here: >=20 > [2] > https://lore.kernel.org/linux-mm/33a1cb67-8d23-4b51-b4d8-9e95e8de00c7@k= ernel.org/ >=20 > -- > With Best Regards, > Shengming --=20 Cheers, Harry / Hyeonggon --------------jgzpjNmUZ6ZOyMcxhrm0Gj91-- --------------6NUTL4gdv4n2o3m1W8I1bwuM Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQQ1ub6gR5ogjaKRmOGXBN6rc5S1gUCal+B2wAKCRCGXBN6rc5S 1kN6AP45uf+4RVMMyJ3mYREKVcE6UcDqjuDX/Ms9a7X7JjYBJgEA62nxQ3AvVp4J kyckf9WSiNv7BKqpy488q5sKTSbPQAg= =lhZl -----END PGP SIGNATURE----- --------------6NUTL4gdv4n2o3m1W8I1bwuM--