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

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

[hu.shengming]

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>
---
Changes in v3:
- Replace “normal memory” with the more precise “non-pfmemalloc slabs”,
  and add Fixes: and Cc: stable@vger.kernel.org, as suggested by Harry.
- Link to v2: https://lore.kernel.org/all/20260720211127124sYtTNbvsxCXN9_pDh-pwt@zte.com.cn/

Changes in v2:
- Add __GFP_NOWARN as suggested by Hao.
- Link to v1: https://lore.kernel.org/all/20260719113701797vZ3R8NxiqYt8dEfeUxtON@zte.com.cn/

---
 mm/slub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/slub.c b/mm/slub.c
index 53b4976d3831..357b7522c817 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) >= MAX_FULL_SHEAVES ||
-	    refill_sheaf(s, sheaf, gfp)) {
+	    refill_sheaf(s, sheaf, gfp | __GFP_NOMEMALLOC | __GFP_NOWARN)) {
 		sheaf_flush_unused(s, sheaf);
 		free_empty_sheaf(s, sheaf);
 		return;
-- 
2.25.1

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

[Harry Yoo]

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



On 7/21/26 9:45 AM, 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>
> ---

Looks good to me,
Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org>

> Changes in v3:
> - Replace “normal memory” with the more precise “non-pfmemalloc slabs”,
>   and add Fixes: and Cc: stable@vger.kernel.org, as suggested by Harry.
> - Link to v2: https://lore.kernel.org/all/20260720211127124sYtTNbvsxCXN9_pDh-pwt@zte.com.cn/
> 
> Changes in v2:
> - Add __GFP_NOWARN as suggested by Hao.
> - Link to v1: https://lore.kernel.org/all/20260719113701797vZ3R8NxiqYt8dEfeUxtON@zte.com.cn/
> 
> ---
>  mm/slub.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 53b4976d3831..357b7522c817 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) >= MAX_FULL_SHEAVES ||
> -	    refill_sheaf(s, sheaf, gfp)) {
> +	    refill_sheaf(s, sheaf, gfp | __GFP_NOMEMALLOC | __GFP_NOWARN)) {
>  		sheaf_flush_unused(s, sheaf);
>  		free_empty_sheaf(s, sheaf);
>  		return;

-- 
Cheers,
Harry / Hyeonggon

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

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

[Hao Li]

On Tue, Jul 21, 2026 at 08:45:22AM +0800, 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>

LGTM
Reviewed-by: Hao Li <hao.li@linux.dev>

-- 
Thanks,
Hao

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

[Vlastimil Babka (SUSE)]

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")

Wonder if 1ce20c28eafd ("slab: handle pfmemalloc slabs properly with
sheaves") is a better match. Until that commit we just didn't care, and it
seems like this is a case that commit missed?

> Cc: stable@vger.kernel.org
> Signed-off-by: Shengming Hu <hu.shengming@zte.com.cn>
> ---
> Changes in v3:
> - Replace “normal memory” with the more precise “non-pfmemalloc slabs”,
>   and add Fixes: and Cc: stable@vger.kernel.org, as suggested by Harry.
> - Link to v2: https://lore.kernel.org/all/20260720211127124sYtTNbvsxCXN9_pDh-pwt@zte.com.cn/
> 
> Changes in v2:
> - Add __GFP_NOWARN as suggested by Hao.
> - Link to v1: https://lore.kernel.org/all/20260719113701797vZ3R8NxiqYt8dEfeUxtON@zte.com.cn/
> 
> ---
>  mm/slub.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 53b4976d3831..357b7522c817 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) >= MAX_FULL_SHEAVES ||
> -	    refill_sheaf(s, sheaf, gfp)) {
> +	    refill_sheaf(s, sheaf, gfp | __GFP_NOMEMALLOC | __GFP_NOWARN)) {
>  		sheaf_flush_unused(s, sheaf);
>  		free_empty_sheaf(s, sheaf);
>  		return;

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

[Vlastimil Babka (SUSE)]

On 7/21/26 09:34, Vlastimil Babka (SUSE) 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")
> 
> Wonder if 1ce20c28eafd ("slab: handle pfmemalloc slabs properly with
> sheaves") is a better match. Until that commit we just didn't care, and it
> seems like this is a case that commit missed?

Added to slab/for-next with changed Fixes: per above, but can adjust it
further if it was wrong. Thanks!

>> Cc: stable@vger.kernel.org
>> Signed-off-by: Shengming Hu <hu.shengming@zte.com.cn>
>> ---
>> Changes in v3:
>> - Replace “normal memory” with the more precise “non-pfmemalloc slabs”,
>>   and add Fixes: and Cc: stable@vger.kernel.org, as suggested by Harry.
>> - Link to v2: https://lore.kernel.org/all/20260720211127124sYtTNbvsxCXN9_pDh-pwt@zte.com.cn/
>> 
>> Changes in v2:
>> - Add __GFP_NOWARN as suggested by Hao.
>> - Link to v1: https://lore.kernel.org/all/20260719113701797vZ3R8NxiqYt8dEfeUxtON@zte.com.cn/
>> 
>> ---
>>  mm/slub.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/mm/slub.c b/mm/slub.c
>> index 53b4976d3831..357b7522c817 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) >= MAX_FULL_SHEAVES ||
>> -	    refill_sheaf(s, sheaf, gfp)) {
>> +	    refill_sheaf(s, sheaf, gfp | __GFP_NOMEMALLOC | __GFP_NOWARN)) {
>>  		sheaf_flush_unused(s, sheaf);
>>  		free_empty_sheaf(s, sheaf);
>>  		return;
> 

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

[Vlastimil Babka (SUSE)]

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

> ---
> Changes in v3:
> - Replace “normal memory” with the more precise “non-pfmemalloc slabs”,
>   and add Fixes: and Cc: stable@vger.kernel.org, as suggested by Harry.
> - Link to v2: https://lore.kernel.org/all/20260720211127124sYtTNbvsxCXN9_pDh-pwt@zte.com.cn/
> 
> Changes in v2:
> - Add __GFP_NOWARN as suggested by Hao.
> - Link to v1: https://lore.kernel.org/all/20260719113701797vZ3R8NxiqYt8dEfeUxtON@zte.com.cn/
> 
> ---
>  mm/slub.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 53b4976d3831..357b7522c817 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) >= MAX_FULL_SHEAVES ||
> -	    refill_sheaf(s, sheaf, gfp)) {
> +	    refill_sheaf(s, sheaf, gfp | __GFP_NOMEMALLOC | __GFP_NOWARN)) {
>  		sheaf_flush_unused(s, sheaf);
>  		free_empty_sheaf(s, sheaf);
>  		return;

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

[hu.shengming]

Vlastimil wrote:
> On 7/21/26 09:34, Vlastimil Babka (SUSE) 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")
> > 
> > Wonder if 1ce20c28eafd ("slab: handle pfmemalloc slabs properly with
> > sheaves") is a better match. Until that commit we just didn't care, and it
> > seems like this is a case that commit missed?

Agreed, 1ce20c28eafd is a better match. Thanks for catching this.

> Added to slab/for-next with changed Fixes: per above, but can adjust it
> further if it was wrong. Thanks!
> 

Thanks!

--
With Best Regards,
Shengming

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

[hu.shengming]

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 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@kernel.org/

--
With Best Regards,
Shengming

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

[Harry Yoo]

[-- 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 --]

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

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@kernel.org/
>> 
>> --
>> With Best Regards,
>> Shengming
> 

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

[Harry Yoo]

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



On 7/21/26 6:04 PM, hu.shengming@zte.com.cn wrote:
> Vlastimil wrote:
>> On 7/21/26 09:34, Vlastimil Babka (SUSE) 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")
>>>
>>> Wonder if 1ce20c28eafd ("slab: handle pfmemalloc slabs properly with
>>> sheaves") is a better match. Until that commit we just didn't care, and it
>>> seems like this is a case that commit missed?
> 
> Agreed, 1ce20c28eafd is a better match. Thanks for catching this.

Agreed, thanks!

-- 
Cheers,
Harry / Hyeonggon


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