[syzbot] [mm?] WARNING in alloc_frozen_pages_noprof

[syzbot] [mm?] WARNING in alloc_frozen_pages_noprof

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    8f5ae30d69d7 Linux 6.17-rc1
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=1568cc34580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=8c5ac3d8b8abfcb
dashboard link: https://syzkaller.appspot.com/bug?extid=3f9768ec54c86997ddfb
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
userspace arch: arm64
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=132b19a2580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=164da842580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/18a2e4bd0c4a/disk-8f5ae30d.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/3b5395881b25/vmlinux-8f5ae30d.xz
kernel image: https://storage.googleapis.com/syzbot-assets/e875f4e3b7ff/Image-8f5ae30d.gz.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3f9768ec54c86997ddfb@syzkaller.appspotmail.com

------------[ cut here ]------------
WARNING: CPU: 1 PID: 6777 at mm/page_alloc.c:5124 __alloc_frozen_pages_noprof+0xd0/0x318 mm/page_alloc.c:5124
Modules linked in:
CPU: 1 UID: 0 PID: 6777 Comm: syz.0.17 Not tainted 6.17.0-rc1-syzkaller-g8f5ae30d69d7 #0 PREEMPT 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/18/2025
pstate: 23400005 (nzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : __alloc_frozen_pages_noprof+0xd0/0x318 mm/page_alloc.c:5124
lr : __alloc_frozen_pages_noprof+0xac/0x318 mm/page_alloc.c:5118
sp : ffff8000a3d575e0
x29: ffff8000a3d576b0 x28: 1fffe00018f73d00 x27: ffff8000a3d57980
x26: 1ffff00012eb431c x25: dfff800000000000 x24: ffff8000a3d57600
x23: ffff7000147aaec0 x22: 0000000000000000 x21: 0000000000040d40
x20: 0000000000000000 x19: 0000000000000024 x18: 1fffe000337a0688
x17: ffff0001fea8c8b0 x16: ffff80008af6de48 x15: 0000000000000005
x14: 1ffff000147aaec4 x13: 0000000000000000 x12: 0000000000000000
x11: ffff7000147aaec9 x10: dfff800000000000 x9 : 0000000000000001
x8 : ffff800092df4000 x7 : 0000000000000000 x6 : ffff8000802312a4
x5 : ffff0000c7b3db38 x4 : 0000000000000000 x3 : 0000000000000020
x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
 __alloc_frozen_pages_noprof+0xd0/0x318 mm/page_alloc.c:5124 (P)
 alloc_pages_mpol+0x1e4/0x460 mm/mempolicy.c:2416
 alloc_frozen_pages_noprof+0xe0/0x210 mm/mempolicy.c:2487
 ___kmalloc_large_node+0xac/0x154 mm/slub.c:4306
 __kmalloc_large_node_noprof+0x2c/0x8c mm/slub.c:4337
 __do_kmalloc_node mm/slub.c:4353 [inline]
 __kmalloc_noprof+0x3bc/0x4c8 mm/slub.c:4377
 kmalloc_noprof include/linux/slab.h:909 [inline]
 kzalloc_noprof include/linux/slab.h:1039 [inline]
 v9fs_fid_get_acl+0x64/0x114 fs/9p/acl.c:32
 __v9fs_get_acl fs/9p/acl.c:66 [inline]
 v9fs_get_acl+0xa8/0x3ac fs/9p/acl.c:92
 v9fs_qid_iget_dotl fs/9p/vfs_inode_dotl.c:131 [inline]
 v9fs_inode_from_fid_dotl+0x1d8/0x26c fs/9p/vfs_inode_dotl.c:154
 v9fs_get_new_inode_from_fid fs/9p/v9fs.h:251 [inline]
 v9fs_mount+0x5b8/0x910 fs/9p/vfs_super.c:144
 legacy_get_tree+0xd4/0x16c fs/fs_context.c:666
 vfs_get_tree+0x90/0x28c fs/super.c:1815
 do_new_mount+0x278/0x7f4 fs/namespace.c:3805
 path_mount+0x5b4/0xde0 fs/namespace.c:4120
 do_mount fs/namespace.c:4133 [inline]
 __do_sys_mount fs/namespace.c:4344 [inline]
 __se_sys_mount fs/namespace.c:4321 [inline]
 __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4321
 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
 invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
 el0_svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879
 el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898
 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:596
irq event stamp: 3156
hardirqs last  enabled at (3155): [<ffff800080c6f5fc>] kasan_quarantine_put+0x1a0/0x1c8 mm/kasan/quarantine.c:234
hardirqs last disabled at (3156): [<ffff80008b001bfc>] el1_brk64+0x1c/0x48 arch/arm64/kernel/entry-common.c:574
softirqs last  enabled at (2974): [<ffff800080aab748>] spin_unlock_bh include/linux/spinlock.h:396 [inline]
softirqs last  enabled at (2974): [<ffff800080aab748>] bdi_register_va+0x534/0x7e4 mm/backing-dev.c:1114
softirqs last disabled at (2972): [<ffff800080aab534>] spin_lock_bh include/linux/spinlock.h:356 [inline]
softirqs last disabled at (2972): [<ffff800080aab534>] bdi_register_va+0x320/0x7e4 mm/backing-dev.c:1104
---[ end trace 0000000000000000 ]---


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [mm?] WARNING in alloc_frozen_pages_noprof

[Harry Yoo]

On Tue, Aug 12, 2025 at 02:56:35PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    8f5ae30d69d7 Linux 6.17-rc1
> git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
> console output: https://syzkaller.appspot.com/x/log.txt?x=1568cc34580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=8c5ac3d8b8abfcb
> dashboard link: https://syzkaller.appspot.com/bug?extid=3f9768ec54c86997ddfb
> compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> userspace arch: arm64
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=132b19a2580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=164da842580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/18a2e4bd0c4a/disk-8f5ae30d.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/3b5395881b25/vmlinux-8f5ae30d.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/e875f4e3b7ff/Image-8f5ae30d.gz.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+3f9768ec54c86997ddfb@syzkaller.appspotmail.com
> 
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 6777 at mm/page_alloc.c:5124 __alloc_frozen_pages_noprof+0xd0/0x318 mm/page_alloc.c:5124
> Modules linked in:
> CPU: 1 UID: 0 PID: 6777 Comm: syz.0.17 Not tainted 6.17.0-rc1-syzkaller-g8f5ae30d69d7 #0 PREEMPT 
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/18/2025
> pstate: 23400005 (nzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
> pc : __alloc_frozen_pages_noprof+0xd0/0x318 mm/page_alloc.c:5124
> lr : __alloc_frozen_pages_noprof+0xac/0x318 mm/page_alloc.c:5118
> sp : ffff8000a3d575e0
> x29: ffff8000a3d576b0 x28: 1fffe00018f73d00 x27: ffff8000a3d57980
> x26: 1ffff00012eb431c x25: dfff800000000000 x24: ffff8000a3d57600
> x23: ffff7000147aaec0 x22: 0000000000000000 x21: 0000000000040d40
> x20: 0000000000000000 x19: 0000000000000024 x18: 1fffe000337a0688
> x17: ffff0001fea8c8b0 x16: ffff80008af6de48 x15: 0000000000000005
> x14: 1ffff000147aaec4 x13: 0000000000000000 x12: 0000000000000000
> x11: ffff7000147aaec9 x10: dfff800000000000 x9 : 0000000000000001
> x8 : ffff800092df4000 x7 : 0000000000000000 x6 : ffff8000802312a4
> x5 : ffff0000c7b3db38 x4 : 0000000000000000 x3 : 0000000000000020
> x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000
> Call trace:
>  __alloc_frozen_pages_noprof+0xd0/0x318 mm/page_alloc.c:5124 (P)

The warning is:

	/*
	 * There are several places where we assume that the order value is sane
	 * so bail out early if the request is out of bound.
	 */
	if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp))
		return NULL;

There's not much the buddy allocator can do when a user requests
order > MAX_PAGE_ORDER allocations.

>  alloc_pages_mpol+0x1e4/0x460 mm/mempolicy.c:2416
>  alloc_frozen_pages_noprof+0xe0/0x210 mm/mempolicy.c:2487
>  ___kmalloc_large_node+0xac/0x154 mm/slub.c:4306
>  __kmalloc_large_node_noprof+0x2c/0x8c mm/slub.c:4337
>  __do_kmalloc_node mm/slub.c:4353 [inline]
>  __kmalloc_noprof+0x3bc/0x4c8 mm/slub.c:4377
>  kmalloc_noprof include/linux/slab.h:909 [inline]
>  kzalloc_noprof include/linux/slab.h:1039 [inline]
>  v9fs_fid_get_acl+0x64/0x114 fs/9p/acl.c:32

So... 9p FS shouldn't really request that?

Cc'ing 9p FS folks.

>  __v9fs_get_acl fs/9p/acl.c:66 [inline]
>  v9fs_get_acl+0xa8/0x3ac fs/9p/acl.c:92
>  v9fs_qid_iget_dotl fs/9p/vfs_inode_dotl.c:131 [inline]
>  v9fs_inode_from_fid_dotl+0x1d8/0x26c fs/9p/vfs_inode_dotl.c:154
>  v9fs_get_new_inode_from_fid fs/9p/v9fs.h:251 [inline]
>  v9fs_mount+0x5b8/0x910 fs/9p/vfs_super.c:144
>  legacy_get_tree+0xd4/0x16c fs/fs_context.c:666
>  vfs_get_tree+0x90/0x28c fs/super.c:1815
>  do_new_mount+0x278/0x7f4 fs/namespace.c:3805
>  path_mount+0x5b4/0xde0 fs/namespace.c:4120
>  do_mount fs/namespace.c:4133 [inline]
>  __do_sys_mount fs/namespace.c:4344 [inline]
>  __se_sys_mount fs/namespace.c:4321 [inline]
>  __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4321
>  __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
>  invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
>  el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
>  do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
>  el0_svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879
>  el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898
>  el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:596
> irq event stamp: 3156
> hardirqs last  enabled at (3155): [<ffff800080c6f5fc>] kasan_quarantine_put+0x1a0/0x1c8 mm/kasan/quarantine.c:234
> hardirqs last disabled at (3156): [<ffff80008b001bfc>] el1_brk64+0x1c/0x48 arch/arm64/kernel/entry-common.c:574
> softirqs last  enabled at (2974): [<ffff800080aab748>] spin_unlock_bh include/linux/spinlock.h:396 [inline]
> softirqs last  enabled at (2974): [<ffff800080aab748>] bdi_register_va+0x534/0x7e4 mm/backing-dev.c:1114
> softirqs last disabled at (2972): [<ffff800080aab534>] spin_lock_bh include/linux/spinlock.h:356 [inline]
> softirqs last disabled at (2972): [<ffff800080aab534>] bdi_register_va+0x320/0x7e4 mm/backing-dev.c:1104
> ---[ end trace 0000000000000000 ]---
> 
> 
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> 
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
> 
> If you want syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
> 
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
> 
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
> 
> If you want to undo deduplication, reply with:
> #syz undup

Re: [syzbot] [mm?] WARNING in alloc_frozen_pages_noprof

[Dominique Martinet]

Harry Yoo wrote on Wed, Aug 13, 2025 at 09:31:34AM +0900:
> The warning is:
> 
> 	/*
> 	 * There are several places where we assume that the order value is sane
> 	 * so bail out early if the request is out of bound.
> 	 */
> 	if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp))
> 		return NULL;
> 
> There's not much the buddy allocator can do when a user requests
> order > MAX_PAGE_ORDER allocations.
> 
> >  alloc_pages_mpol+0x1e4/0x460 mm/mempolicy.c:2416
> >  alloc_frozen_pages_noprof+0xe0/0x210 mm/mempolicy.c:2487
> >  ___kmalloc_large_node+0xac/0x154 mm/slub.c:4306
> >  __kmalloc_large_node_noprof+0x2c/0x8c mm/slub.c:4337
> >  __do_kmalloc_node mm/slub.c:4353 [inline]
> >  __kmalloc_noprof+0x3bc/0x4c8 mm/slub.c:4377
> >  kmalloc_noprof include/linux/slab.h:909 [inline]
> >  kzalloc_noprof include/linux/slab.h:1039 [inline]
> >  v9fs_fid_get_acl+0x64/0x114 fs/9p/acl.c:32
> 
> So... 9p FS shouldn't really request that?
> 
> Cc'ing 9p FS folks.

Thanks for the Cc.

So, this comes up once in a while, everytime we discuss limiting the
xattr size, then someone says we should do something else or I'm using
the wrong define or I don't remember and then when I ask what we should
do never reply again.

See [1] or [2] for the last two time this happened.
[1] https://lore.kernel.org/all/20240304-xattr_maxsize-v1-1-322357ec6bdf@codewreck.org/T/#u
[2] https://lore.kernel.org/lkml/20240202121319.21743-1-pchelkin@ispras.ru/

I'll be happy to take any patch you send (or one of the older patches if
you tell me which is "correct"), I don't care anymore.
-- 
Dominique

Re: [syzbot] [mm?] WARNING in alloc_frozen_pages_noprof

[Christian Schoenebeck]

On Wednesday, August 13, 2025 6:49:02 AM CEST Dominique Martinet wrote:
> Harry Yoo wrote on Wed, Aug 13, 2025 at 09:31:34AM +0900:
> > The warning is:
> > 
> > 	/*
> > 	 * There are several places where we assume that the order value is sane
> > 	 * so bail out early if the request is out of bound.
> > 	 */
> > 	if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp))
> > 		return NULL;
> > 
> > There's not much the buddy allocator can do when a user requests
> > order > MAX_PAGE_ORDER allocations.
> > 
> > >  alloc_pages_mpol+0x1e4/0x460 mm/mempolicy.c:2416
> > >  alloc_frozen_pages_noprof+0xe0/0x210 mm/mempolicy.c:2487
> > >  ___kmalloc_large_node+0xac/0x154 mm/slub.c:4306
> > >  __kmalloc_large_node_noprof+0x2c/0x8c mm/slub.c:4337
> > >  __do_kmalloc_node mm/slub.c:4353 [inline]
> > >  __kmalloc_noprof+0x3bc/0x4c8 mm/slub.c:4377
> > >  kmalloc_noprof include/linux/slab.h:909 [inline]
> > >  kzalloc_noprof include/linux/slab.h:1039 [inline]
> > >  v9fs_fid_get_acl+0x64/0x114 fs/9p/acl.c:32
> > 
> > So... 9p FS shouldn't really request that?
> > 
> > Cc'ing 9p FS folks.
> 
> Thanks for the Cc.
> 
> So, this comes up once in a while, everytime we discuss limiting the
> xattr size, then someone says we should do something else or I'm using
> the wrong define or I don't remember and then when I ask what we should
> do never reply again.
> 
> See [1] or [2] for the last two time this happened.
> [1] https://lore.kernel.org/all/20240304-xattr_maxsize-v1-1-322357ec6bdf@codewreck.org/T/#u
> [2] https://lore.kernel.org/lkml/20240202121319.21743-1-pchelkin@ispras.ru/
> 
> I'll be happy to take any patch you send (or one of the older patches if
> you tell me which is "correct"), I don't care anymore.
> 

Not that I would care much either, but as nobody else responded, I still think
the following is the way to go:

diff --git a/fs/9p/xattr.c b/fs/9p/xattr.c
index 8604e3377ee7..97f60b73bf16 100644
--- a/fs/9p/xattr.c
+++ b/fs/9p/xattr.c
@@ -37,8 +37,8 @@ ssize_t v9fs_fid_xattr_get(struct p9_fid *fid, const char *name,
 	if (attr_size > buffer_size) {
 		if (buffer_size)
 			retval = -ERANGE;
-		else if (attr_size > SSIZE_MAX)
-			retval = -EOVERFLOW;
+		else if (attr_size > KMALLOC_MAX_SIZE)
+			retval = -E2BIG;
 		else /* request to get the attr_size */
 			retval = attr_size;
 	} else {

---

Values > KMALLOC_MAX_SIZE are triggering the reported warning.

XATTR_SIZE_MAX (64k) would be much smaller than KMALLOC_MAX_SIZE (4M).

The call stack in question comes from ACL handling. In this case there is no 
XATTR_SIZE_MAX limit involved on 9p client side. If 9p server side does,
then server responds with an error anyway. If however server does not have
this limit then why limiting it to XATTR_SIZE_MAX on client side for all?

And if OTOH the call stack comes from the general purpose xattr API (i.e. not
ACL stuff), then there is already a XATTR_SIZE_MAX check on xattr VFS layer.
So no need to check for XATTR_SIZE_MAX on 9p layer for a 2nd time:

https://github.com/torvalds/linux/blob/d7ee5bdce7892643409dea7266c34977e651b479/fs/xattr.c#L616

In the end it is merely a theoretical issue. POSIX ACLs are quite compact
encoded into xattrs. To fill 64k you need a ridiculous large set of ACLs.

/Christian