Re: [PATCH v3] mm/slub: prevent pfmemalloc objects from entering the barn

[Harry Yoo <harry@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2425 bytes --]



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 <hu.shengming@zte.com.cn>
>>>
>>> kmem_cache_return_sheaf() may refill a partially consumed sheaf before
>>> 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 acceptable.
>>> If the refill fails, flush and free the sheaf instead.
>>>
>>> Fixes: 3c1ea5c5019f ("slab: sheaf prefilling for guaranteed allocations")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Shengming Hu <hu.shengming@zte.com.cn>
>>
>> Ah so per sashiko [1] we should consider adding also a __GFP_NORETRY to
>> avoid an OOM kill. Seems reasonable that an API for returning memory should
>> 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
> 
> Agreed, adding __GFP_NORETRY seems reasonable, since this best-effort
> refill should not trigger the OOM killer.
> 
> However, I wonder whether the same scope consideration that Harry raised
> 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:
> 
> [2]
> https://lore.kernel.org/linux-mm/33a1cb67-8d23-4b51-b4d8-9e95e8de00c7@kernel.org/
> 
> --
> With Best Regards,
> Shengming

-- 
Cheers,
Harry / Hyeonggon


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]