Re: [syzbot] [mm?] INFO: rcu detected stall in kcov_ioctl (3)

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 08 Apr 2026 16:31:27 -0700 syzbot <syzbot+8a59070fc852219166ab@syzkaller.appspotmail.com> wrote:

> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    7ca6d1cfec80 Merge tag 'powerpc-7.0-4' of git://git.kernel..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=133b4dda580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=64e78d99d9bf8b4c
> dashboard link: https://syzkaller.appspot.com/bug?extid=8a59070fc852219166ab
> compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> 
> Unfortunately, I don't have any reproducer for this issue yet.

Thanks.  I added a few kcov names from MAINTAINERS.

> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/ace9641c44ac/disk-7ca6d1cf.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/6e66f8b9476e/vmlinux-7ca6d1cf.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/d679c066df56/bzImage-7ca6d1cf.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+8a59070fc852219166ab@syzkaller.appspotmail.com
> 
> bridge0: received packet on bridge_slave_0 with own address as source address (addr:aa:aa:aa:aa:aa:0c, vlan:0)
> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> rcu: 	Tasks blocked on level-0 rcu_node (CPUs 0-1): P23414/1:b..l P27649/1:b..l P27664/1:b..l
> rcu: 	(detected by 0, t=10502 jiffies, g=200461, q=440 ncpus=2)
> task:syz-executor    state:R  running task     stack:25416 pid:27664 tgid:27664 ppid:5809   task_flags:0x400000 flags:0x00080000
> Call Trace:
>  <TASK>
>  context_switch kernel/sched/core.c:5298 [inline]
>  __schedule+0xfee/0x6120 kernel/sched/core.c:6911
>  preempt_schedule_irq+0x50/0x90 kernel/sched/core.c:7238
>  irqentry_exit+0x17b/0x670 kernel/entry/common.c:239
>  asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
> RIP: 0010:__orc_find+0x49/0xf0 arch/x86/kernel/unwind_orc.c:101
> Code: 00 49 89 fe 48 89 f0 49 39 fc 72 7b 48 b9 00 00 00 00 00 fc ff df 49 89 ff 48 89 fd eb 0c 48 8d 6b 04 49 89 df 49 39 ec 72 4e <4c> 89 e2 48 29 ea 48 89 d6 48 c1 ea 3f 48 c1 fe 02 48 01 f2 48 d1
> RSP: 0018:ffffc9000d12f138 EFLAGS: 00000212
> RAX: ffffffff91777f46 RBX: ffffffff90f165c4 RCX: dffffc0000000000
> RDX: ffffffff81aecd9f RSI: 0000000000000000 RDI: ffffffff90f165b8
> RBP: ffffffff90f165b8 R08: ffffffff91777f70 R09: 0000000000000007
> R10: 0000000000000200 R11: 000000000000aecd R12: ffffffff90f165c0
> R13: ffffffff81aecd22 R14: ffffffff90f165b8 R15: ffffffff90f165b8
>  orc_find arch/x86/kernel/unwind_orc.c:238 [inline]
>  unwind_next_frame+0x2ec/0x1ea0 arch/x86/kernel/unwind_orc.c:510
>  __unwind_start+0x3d1/0x7f0 arch/x86/kernel/unwind_orc.c:773
>  unwind_start arch/x86/include/asm/unwind.h:64 [inline]
>  arch_stack_walk+0x73/0xf0 arch/x86/kernel/stacktrace.c:24
>  stack_trace_save+0x8e/0xc0 kernel/stacktrace.c:122
>  save_stack+0x162/0x1e0 mm/page_owner.c:165
>  __set_page_owner+0x8c/0x540 mm/page_owner.c:341
>  set_page_owner include/linux/page_owner.h:32 [inline]
>  post_alloc_hook+0x153/0x170 mm/page_alloc.c:1889
>  prep_new_page mm/page_alloc.c:1897 [inline]
>  get_page_from_freelist+0x111d/0x3140 mm/page_alloc.c:3962
>  __alloc_frozen_pages_noprof+0x27c/0x2ba0 mm/page_alloc.c:5250
>  __alloc_pages_noprof mm/page_alloc.c:5284 [inline]
>  alloc_pages_bulk_noprof+0x782/0x1490 mm/page_alloc.c:5204
>  ___alloc_pages_bulk mm/kasan/shadow.c:345 [inline]
>  __kasan_populate_vmalloc_do mm/kasan/shadow.c:370 [inline]
>  __kasan_populate_vmalloc+0xf0/0x210 mm/kasan/shadow.c:424
>  kasan_populate_vmalloc include/linux/kasan.h:580 [inline]
>  alloc_vmap_area+0x95d/0x2bd0 mm/vmalloc.c:2129
>  __get_vm_area_node+0x1ca/0x330 mm/vmalloc.c:3232
>  __vmalloc_node_range_noprof+0x213/0x1530 mm/vmalloc.c:4024
>  vmalloc_user_noprof+0x9e/0xe0 mm/vmalloc.c:4218
>  kcov_ioctl+0x4c/0x720 kernel/kcov.c:726
>  vfs_ioctl fs/ioctl.c:51 [inline]

I assume the fuzzer is asking kcov_ioctl() to allocate ludicrous
amounts of memory.

	case KCOV_INIT_TRACE:
		/*
		 * Enable kcov in trace mode and setup buffer size.
		 * Must happen before anything else.
		 *
		 * First check the size argument - it must be at least 2
		 * to hold the current position and one PC.
		 */
		size = arg;
		if (size < 2 || size > INT_MAX / sizeof(unsigned long))
			return -EINVAL;
		area = vmalloc_user(size * sizeof(unsigned long));

KCOV_REMOTE_MAX_HANDLES looks to be OK.

/sys/debug/kcov is mode 0600 so this is no emergency.

Maintainers, perhaps we can do something more ... restrained here?