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

[Vlastimil Babka (SUSE)]

On 7/21/26 16:27, Harry Yoo wrote:
> On 7/21/26 6:17 PM, hu.shengming@xxxxxxxxxx wrote:
>> Vlastimil wrote:
>>> On 7/21/26 02:45, hu.shengming@xxxxxxxxxx wrote:
>>>> From: Shengming Hu <hu.shengming@xxxxxxxxxx>
>>>>
>>>> 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@xxxxxxxxxxxxxxx
>>>> Signed-off-by: Shengming Hu <hu.shengming@xxxxxxxxxx>
>>>
>>> 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.

Indeed, let's do that as a separate cleanup.

>> 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.

Yeah I won't add __GFP_NORETRY to this patch.

Thanks!

>> The earlier discussion is here:
>> 
>> [2]
>> https://lore.kernel.org/linux-mm/33a1cb67-8d23-4b51-b4d8-9e95e8de00c7@xxxxxxxxxx/
>> 
>> --
>> With Best Regards,
>> Shengming
>