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

From: hu.shengming

Date: Tue Jul 21 2026 - 05:18:51 EST


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 but I
> thought defaulting to GFP_NOWAIT would be an unnecessary limitation.
>
> 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.

The earlier discussion is here:

[2]
https://lore.kernel.org/linux-mm/33a1cb67-8d23-4b51-b4d8-9e95e8de00c7@xxxxxxxxxx/

--
With Best Regards,
Shengming