[Kernel Bug] WARNING in mempool_alloc_noprof

[李龙兴]

Dear Linux kernel developers and maintainers,

We would like to report a new kernel bug found by our tool. WARNING in
mempool_alloc_noprof. Details are as follows.

Kernel commit: v6.12.11
Kernel config: see attachment
report: see attachment

We are currently analyzing the root cause and working on a
reproducible PoC. We will provide further updates in this thread as
soon as we have more information.

Best regards,
Longxing Li

------------[ cut here ]------------
WARNING: CPU: 1 PID: 362734 at mm/page_alloc.c:4234
__alloc_pages_slowpath mm/page_alloc.c:4234 [inline]
WARNING: CPU: 1 PID: 362734 at mm/page_alloc.c:4234
__alloc_pages_noprof+0x2025/0x25a0 mm/page_alloc.c:4766
Modules linked in:
CPU: 1 UID: 0 PID: 362734 Comm: syz-executor.5 Not tainted 6.12.11 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:__alloc_pages_slowpath mm/page_alloc.c:4234 [inline]
RIP: 0010:__alloc_pages_noprof+0x2025/0x25a0 mm/page_alloc.c:4766
Code: 10 00 00 00 44 8b 74 24 48 41 89 c5 0f b6 c0 44 8b a4 24 84 00
00 00 89 44 24 28 e9 e5 f6 ff ff 90 0f 0b 90 e9 f1 f6 ff ff 90 <0f> 0b
90 e9 1e fb ff ff e8 2e a4 38 09 e9 5e ed ff ff 4c 89 f7 e8
RSP: 0000:ffffc9003ce9e7d0 EFLAGS: 00010246
RAX: 0000000000008000 RBX: 0000000000000000 RCX: ffffc9003ce9e8fc
RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88813fff99c8
RBP: 0000000000000000 R08: 000000000000028d R09: 0000000000000000
R10: ffff88807fffbc17 R11: 0000000000000000 R12: 000000000009a800
R13: 000000000009a800 R14: 1ffff920079d3d0e R15: 0000000000000001
FS: 00007f1784eff640(0000) GS:ffff888135e00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055bb25a85a28 CR3: 0000000096938000 CR4: 0000000000752ef0
PKRU: 55555554
Call Trace:
<TASK>
alloc_pages_mpol_noprof+0x2c9/0x610 mm/mempolicy.c:2269
mempool_alloc_noprof+0x176/0x390 mm/mempool.c:402
fscrypt_alloc_bounce_page+0x28/0x60 fs/crypto/crypto.c:59
fscrypt_encrypt_pagecache_blocks.cold+0x567/0x6da fs/crypto/crypto.c:202
f2fs_encrypt_one_page+0x187/0x630 fs/f2fs/data.c:2516
f2fs_do_write_data_page+0x7b4/0x1900 fs/f2fs/data.c:2706
f2fs_write_single_data_page+0x1454/0x1c30 fs/f2fs/data.c:2872
f2fs_write_cache_pages+0xd6e/0x24e0 fs/f2fs/data.c:3166
__f2fs_write_data_pages fs/f2fs/data.c:3321 [inline]
f2fs_write_data_pages+0x4af/0xdd0 fs/f2fs/data.c:3348
do_writepages+0x1a3/0x7f0 mm/page-writeback.c:2683
filemap_fdatawrite_wbc mm/filemap.c:398 [inline]
filemap_fdatawrite_wbc+0x148/0x1c0 mm/filemap.c:388
__filemap_fdatawrite_range+0xb3/0xf0 mm/filemap.c:431
file_write_and_wait_range+0xca/0x140 mm/filemap.c:788
f2fs_do_sync_file+0x2dc/0x1ed0 fs/f2fs/file.c:278
f2fs_sync_file+0x13a/0x1a0 fs/f2fs/file.c:395
vfs_fsync_range+0x136/0x220 fs/sync.c:188
generic_write_sync include/linux/fs.h:2871 [inline]
f2fs_file_write_iter+0x12ba/0x2370 fs/f2fs/file.c:5057
new_sync_write fs/read_write.c:590 [inline]
vfs_write+0x5ae/0x1150 fs/read_write.c:683
ksys_write+0x12f/0x260 fs/read_write.c:736
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x471ecd
Code: c3 e8 17 28 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f1784eff058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000059bf80 RCX: 0000000000471ecd
RDX: 0000000000000002 RSI: 00000000200003c0 RDI: 0000000000000004
RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000059bf8c
R13: 000000000000000b R14: 000000000059bf80 R15: 00007f1784edf000
</TASK>

https://drive.google.com/file/d/17HbDTI_iPjA72SkV5MnO-_w7IQZ9HIHW/view?usp=drive_link

https://drive.google.com/file/d/19pMiWedcVz8nFrj9jiJXuCjyPbNjYQqq/view?usp=drive_link

[Harry Yoo]

On Mon, Feb 02, 2026 at 02:40:14PM +0800, 李龙兴 wrote:
> Dear Linux kernel developers and maintainers,
>
> We would like to report a new kernel bug found by our tool. WARNING in
> mempool_alloc_noprof. Details are as follows.
>
> Kernel commit: v6.12.11
> Kernel config: see attachment
> report: see attachment
>
> We are currently analyzing the root cause and working on a
> reproducible PoC. We will provide further updates in this thread as
> soon as we have more information.
>
> Best regards,
> Longxing Li
>
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 362734 at mm/page_alloc.c:4234
> __alloc_pages_slowpath mm/page_alloc.c:4234 [inline]
> WARNING: CPU: 1 PID: 362734 at mm/page_alloc.c:4234
> __alloc_pages_noprof+0x2025/0x25a0 mm/page_alloc.c:4766
> Modules linked in:
> CPU: 1 UID: 0 PID: 362734 Comm: syz-executor.5 Not tainted 6.12.11 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> RIP: 0010:__alloc_pages_slowpath mm/page_alloc.c:4234 [inline]
> RIP: 0010:__alloc_pages_noprof+0x2025/0x25a0 mm/page_alloc.c:4766

page allocator triggers a warning when __GFP_NOFAIL is set but
__GFP_DIRECT_RECLAIM is not set.

> Code: 10 00 00 00 44 8b 74 24 48 41 89 c5 0f b6 c0 44 8b a4 24 84 00
> 00 00 89 44 24 28 e9 e5 f6 ff ff 90 0f 0b 90 e9 f1 f6 ff ff 90 <0f> 0b
> 90 e9 1e fb ff ff e8 2e a4 38 09 e9 5e ed ff ff 4c 89 f7 e8
> RSP: 0000:ffffc9003ce9e7d0 EFLAGS: 00010246
> RAX: 0000000000008000 RBX: 0000000000000000 RCX: ffffc9003ce9e8fc
> RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88813fff99c8
> RBP: 0000000000000000 R08: 000000000000028d R09: 0000000000000000
> R10: ffff88807fffbc17 R11: 0000000000000000 R12: 000000000009a800
> R13: 000000000009a800 R14: 1ffff920079d3d0e R15: 0000000000000001
> FS: 00007f1784eff640(0000) GS:ffff888135e00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000055bb25a85a28 CR3: 0000000096938000 CR4: 0000000000752ef0
> PKRU: 55555554
> Call Trace:
> <TASK>
> alloc_pages_mpol_noprof+0x2c9/0x610 mm/mempolicy.c:2269
> mempool_alloc_noprof+0x176/0x390 mm/mempool.c:402

the user of the mempool (f2fs_encrypt_one_page) passed __GFP_DIRECT_RECLAIM,
but mempool temporarily cleared it, but not __GFP_NOFAIL:
gfp_temp = gfp_mask & ~(__GFP_DIRECT_RECLAIM|__GFP_IO)

Hmm perhaps mempool should clear __GFP_NOFAIL as well when clearing
__GFP_DIRECT_RECLAIM?

[Lance Yang]

Good catch!

>
> > Code: 10 00 00 00 44 8b 74 24 48 41 89 c5 0f b6 c0 44 8b a4 24 84 00
> > 00 00 89 44 24 28 e9 e5 f6 ff ff 90 0f 0b 90 e9 f1 f6 ff ff 90 <0f> 0b
> > 90 e9 1e fb ff ff e8 2e a4 38 09 e9 5e ed ff ff 4c 89 f7 e8
> > RSP: 0000:ffffc9003ce9e7d0 EFLAGS: 00010246
> > RAX: 0000000000008000 RBX: 0000000000000000 RCX: ffffc9003ce9e8fc
> > RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88813fff99c8
> > RBP: 0000000000000000 R08: 000000000000028d R09: 0000000000000000
> > R10: ffff88807fffbc17 R11: 0000000000000000 R12: 000000000009a800
> > R13: 000000000009a800 R14: 1ffff920079d3d0e R15: 0000000000000001
> > FS: 00007f1784eff640(0000) GS:ffff888135e00000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 000055bb25a85a28 CR3: 0000000096938000 CR4: 0000000000752ef0
> > PKRU: 55555554
> > Call Trace:
> > <TASK>
> > alloc_pages_mpol_noprof+0x2c9/0x610 mm/mempolicy.c:2269
> > mempool_alloc_noprof+0x176/0x390 mm/mempool.c:402
>
> the user of the mempool (f2fs_encrypt_one_page) passed __GFP_DIRECT_RECLAIM,
> but mempool temporarily cleared it, but not __GFP_NOFAIL:
> gfp_temp = gfp_mask & ~(__GFP_DIRECT_RECLAIM|__GFP_IO)
>
> Hmm perhaps mempool should clear __GFP_NOFAIL as well when clearing
> __GFP_DIRECT_RECLAIM?

Right. Clearing __GFP_NOFAIL together with __GFP_DIRECT_RECLAIM should fix
it, IIUC.

I saw that Vernon's patch does exactly that.

[Vernon Yang]

LGTM. I wrote a fix pacth, as below.

---

From 9131e1b26b1ec55dd38ab08512ed6da0fa7a21f0 Mon Sep 17 00:00:00 2001
From: Vernon Yang <yangli...@kylinos.cn>
Date: Tue, 3 Feb 2026 10:51:45 +0800
Subject: [PATCH] mm: mempool: remove __GFP_NOFAIL gfp_mask when first
allocation

page allocator triggers a warning when __GFP_NOFAIL is set but
__GFP_DIRECT_RECLAIM is not set.

The user of the mempool (f2fs_encrypt_one_page) passed
__GFP_DIRECT_RECLAIM, but mempool temporarily cleared it when
first allocate memory.

gfp_temp = gfp_mask & ~(__GFP_DIRECT_RECLAIM|__GFP_IO)

Make mempool also clear __GFP_NOFAIL as well when clearing
__GFP_DIRECT_RECLAIM.

Closes: https://lore.kernel.org/linux-mm/CAHPqNmwK9TY5THsXWkJuYCdt...@mail.gmail.com
Suggested-by: Harry Yoo <harr...@oracle.com>
Signed-off-by: Vernon Yang <yangli...@kylinos.cn>
---
mm/mempool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/mempool.c b/mm/mempool.c
index c290e5261b47..679ab4a2cc5f 100644
--- a/mm/mempool.c
+++ b/mm/mempool.c
@@ -472,7 +472,7 @@ static unsigned int mempool_alloc_from_pool(struct mempool *pool, void **elems,
static inline gfp_t mempool_adjust_gfp(gfp_t *gfp_mask)
{
*gfp_mask |= __GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_NOWARN;
- return *gfp_mask & ~(__GFP_DIRECT_RECLAIM | __GFP_IO);
+ return *gfp_mask & ~(__GFP_NOFAIL | __GFP_DIRECT_RECLAIM | __GFP_IO);
}

/**
--
2.51.0

--
Thanks,
Vernon

[Vlastimil Babka]

On 2/2/26 07:40, 李龙兴 wrote:
> Dear Linux kernel developers and maintainers,
>
> We would like to report a new kernel bug found by our tool. WARNING in
> mempool_alloc_noprof. Details are as follows.

Hi,

> Kernel commit: v6.12.11

that's a very old version and your reports could get dismissed - in this
case you were lucky. Please use bug finding tools on recent versions.
Ideally even rc kernels (now 6.19-rc7) so new bugs can be fixed before a
final kernel is released.

Thanks,
Vlastimil

[Harry Yoo]

> Closes: https://lore.kernel.org/linux-mm/CAHPqNmwK9TY5THsXWkJuYCdt7x*mZHPq65AUOL...@mail.gmail.com

> Suggested-by: Harry Yoo <harr...@oracle.com>
> Signed-off-by: Vernon Yang <yangli...@kylinos.cn>
> ---

Maybe the changelog could be rephrased a bit,
but overall LGTM, thanks!

[Christoph Hellwig]

On Tue, Feb 03, 2026 at 06:52:39PM +0900, Harry Yoo wrote:
> Maybe the changelog could be rephrased a bit,
> but overall LGTM, thanks!

No, that does not make sense. If mempool is used with __GFP_RECLAIM in
the flags it won't fail, and if it isn't, GFP_NOFAIL can't work.

So if there is any work in mempool_alloc it's that it should warn about
GFP_NOFAIL. The fix is in the callers to not pass the flag, assuming
current kernels still do this.

[Vlastimil Babka]

On 2/3/26 17:27, Christoph Hellwig wrote:
> On Tue, Feb 03, 2026 at 06:52:39PM +0900, Harry Yoo wrote:
>> Maybe the changelog could be rephrased a bit,
>> but overall LGTM, thanks!
>
>
> No, that does not make sense. If mempool is used with __GFP_RECLAIM in
> the flags it won't fail, and if it isn't, GFP_NOFAIL can't work.

So that means as long as there's __GFP_RECLAIM, __GFP_NOFAIL isn't wrong,
just redundant.

> So if there is any work in mempool_alloc it's that it should warn about
> GFP_NOFAIL. The fix is in the callers to not pass the flag, assuming
> current kernels still do this.

We could just tolerate the redundant. The code would be simpler too. But I
don't feel too strongly about it.

[Christoph Hellwig]

On Tue, Feb 03, 2026 at 05:55:27PM +0100, Vlastimil Babka wrote:
> On 2/3/26 17:27, Christoph Hellwig wrote:
> > On Tue, Feb 03, 2026 at 06:52:39PM +0900, Harry Yoo wrote:
> >> Maybe the changelog could be rephrased a bit,
> >> but overall LGTM, thanks!
> >
> >
> > No, that does not make sense. If mempool is used with __GFP_RECLAIM in
> > the flags it won't fail, and if it isn't, GFP_NOFAIL can't work.
>
> So that means as long as there's __GFP_RECLAIM, __GFP_NOFAIL isn't wrong,
> just redundant.

Given how picky the rest of the mm is about __GFP_NOFAIL, silently
accepting it where it has no (or a weird and unexpected) effect
seems like a disservice to the users.

[Vlastimil Babka]

OK then. But I don't think we need to add checks to the mempool hot paths.
If somebody uses __GFP_NOFAIL, eventually it will trickle to the existing
warning that triggered here. If it's using slab then eventually that will
reach the page allocator too. Maybe not with some custom alloc functions,
but meh.

This f2fs_encrypt_one_page() case is weird though (and the relevant parts
seem to be identical in current mainline).
It uses GFP_NOFS, so __GFP_RECLAIM is there. It only adds __GFP_NOFAIL in
case fscrypt_encrypt_pagecache_blocks() already failed with -ENOMEM.

That means fscrypt_alloc_bounce_page() returns NULL, which is either the
WARN_ON_ONCE(!fscrypt_bounce_page_pool) case (but the report doesn't include
such a warning), or mempool_alloc() failed - but that shouldn't happen with
GFP_NOFS?

(Also the !fscrypt_bounce_page_pool is therefore an infinite retry loop,
isn't it? Which would be truly a bug, unless I'm missing something.)

Ah but fscrypt_encrypt_pagecache_blocks() can also return -ENOMEM due to
fscrypt_crypt_data_unit() returning it.

And there theoretically in v6.12.11 skcipher_request_alloc() could return
-ENOMEM. In practice I assume this report was achieved by fault injection.
But that possibility is gone with mainline commit 52e7e0d88933 ("fscrypt:
Switch to sync_skcipher and on-stack requests") anyway.

I think the whole "goto retry_encrypt;" loop in f2fs_encrypt_one_page()
should just be removed.

[Eric Biggers]

Indeed, fscrypt_encrypt_pagecache_blocks() (or the older code it was
derived from) used to do multiple memory allocations. Now it only
allocates the bounce page itself.

Also, the intended usage is what ext4 does: use GFP_NOFS for the first
page in the bio for a guaranteed allocation from the mempool, then
GFP_NOWAIT for any subsequent pages. If any of the subsequent
allocations fails, ext4 submits the bio early and starts a new one.

f2fs does it differently and just always uses GFP_NOFS. Yes, that
doesn't make sense. I guess ideally it would be changed to properly do
opportunistic allocations in the same way as ext4. But until then, just
removing the retry loop sounds good.

- Eric