Re: [syzbot] [mm?] INFO: rcu detected stall in kvm_vm_release (4)

[Ye Liu <ye.liu@linux.dev>]

在 2026/8/21 00:29, Andrew Morton 写道:
> On Thu, 20 Aug 2026 06:16:25 -0700 syzbot <syzbot+5f0b6e2e4195c75b5658@syzkaller.appspotmail.com> wrote:
> 
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:    e8bf40d15402 Merge tag 'chrome-platform-firmware-v7.3' of ..
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1434f815580000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=1941312e3e971b07
>> dashboard link: https://syzkaller.appspot.com/bug?extid=5f0b6e2e4195c75b5658
>> compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
>>
>> Unfortunately, I don't have any reproducer for this issue yet.
>>
>> Downloadable assets:
>> disk image: https://storage.googleapis.com/syzbot-assets/7df7b958efe0/disk-e8bf40d1.raw.xz
>> vmlinux: https://storage.googleapis.com/syzbot-assets/cefbf90e524a/vmlinux-e8bf40d1.xz
>> kernel image: https://storage.googleapis.com/syzbot-assets/37a530b91001/bzImage-e8bf40d1.xz
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+5f0b6e2e4195c75b5658@syzkaller.appspotmail.com
>>
>> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
>> rcu: 	Tasks blocked on level-0 rcu_node (CPUs 0-1): P21500/1:b..l
>> rcu: 	(detected by 0, t=10503 jiffies, g=207513, q=1145 ncpus=2)
>> task:syz.9.4605      state:R  running task     stack:26920 pid:21500 tgid:21500 ppid:14397  task_flags:0x40044c flags:0x00080003
> 
> Thanks.
> 
> lazybutt pasted this into Gemini:
> 	https://share.gemini.google/9rAubqC4qNzf
> 
> : The combination of debug tools: KASAN quarantine processing + ORC
> : unwinder + page_owner stack tracing executed so slowly on the CPU that
> : it exceeded the RCU stall threshold.
> 
> (I think we've recently seen the same thing, different callers)
> 
> I can't say I'm terribly motivated.  page_owner is expensive and if you
> run heavy stress testing with page_owner enabled then such things
> aren't surprising.
> 
> Let me Cc a few page_owner and KASAN people, see if they feel
> differently.

Adding cond_resched() to the qlist_free_all() loop would fix this .
kasan_quarantine_remove_cache() already dose the same in its scanning loop.
> 
>> Call Trace:
>>  <TASK>
>>  context_switch kernel/sched/core.c:5510 [inline]
>>  __schedule+0x17d4/0x5630 kernel/sched/core.c:7239
>>  preempt_schedule_irq+0x4b/0x90 kernel/sched/core.c:7561
>>  irqentry_exit_to_kernel_mode include/linux/irq-entry-common.h:539 [inline]
>>  irqentry_exit+0x14f/0x910 kernel/entry/common.c:167
>>  asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:674
>> RIP: 0010:lock_acquire+0x222/0x350 kernel/locking/lockdep.c:5890
>> Code: ff ff ff e8 c0 0b 32 0a f7 44 24 08 00 02 00 00 0f 84 39 ff ff ff 65 48 8b 05 12 77 cb 11 48 3b 44 24 58 75 33 fb 48 83 c4 60 <5b> 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 48 8d 3d 57 a1 b8
>> RSP: 0018:ffffc900074cf260 EFLAGS: 00000286
>> RAX: 7db047bb98fc4c00 RBX: 0000000000000000 RCX: 0000000000000046
>> RDX: 00000000c0065176 RSI: ffffffff8e4b5735 RDI: ffffffff8c4bdd80
>> RBP: ffffffff8177710f R08: ffffffff8177710f R09: 0000000000000000
>> R10: 0000000000000000 R11: ffffffff8eb5a0e0 R12: 0000000000000002
>> R13: ffffffff8eb5a0e0 R14: 0000000000000000 R15: 0000000000000246
>>  rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
>>  rcu_read_lock include/linux/rcupdate.h:840 [inline]
>>  class_rcu_constructor include/linux/rcupdate.h:1183 [inline]
>>  unwind_next_frame+0xac/0x2550 arch/x86/kernel/unwind_orc.c:495
>>  arch_stack_walk+0x11b/0x150 arch/x86/kernel/stacktrace.c:25
>>  stack_trace_save+0xa9/0x100 kernel/stacktrace.c:122
>>  save_stack+0x122/0x230 mm/page_owner.c:165
>>  __reset_page_owner+0x71/0x1f0 mm/page_owner.c:320
>>  reset_page_owner include/linux/page_owner.h:25 [inline]
>>  __free_pages_prepare mm/page_alloc.c:1406 [inline]
>>  __free_frozen_pages+0xc22/0xd20 mm/page_alloc.c:2950
>>  __slab_free+0x274/0x2c0 mm/slub.c:5741
>>  qlink_free mm/kasan/quarantine.c:163 [inline]
>>  qlist_free_all+0x99/0x100 mm/kasan/quarantine.c:179
>>  kasan_quarantine_reduce+0x148/0x160 mm/kasan/quarantine.c:286
>>  __kasan_slab_alloc+0x22/0x80 mm/kasan/common.c:350
>>  kasan_slab_alloc include/linux/kasan.h:253 [inline]
>>  slab_post_alloc_hook mm/slub.c:4584 [inline]
>>  slab_alloc_node mm/slub.c:4917 [inline]
>>  __do_kmalloc_node mm/slub.c:5333 [inline]
>>  __kmalloc_noprof+0x315/0x720 mm/slub.c:5359
>>  _kmalloc_noprof include/linux/slab.h:992 [inline]
>>  _kzalloc_noprof include/linux/slab.h:1309 [inline]
>>  kobject_get_path+0xc5/0x2f0 lib/kobject.c:161
>>  kobject_uevent_env+0x29e/0x9e0 lib/kobject_uevent.c:548
>>  kvm_uevent_notify_change+0x300/0x3a0 virt/kvm/kvm_main.c:6335
>>  kvm_destroy_vm virt/kvm/kvm_main.c:1260 [inline]
>>  kvm_put_kvm+0xa9/0xb50 virt/kvm/kvm_main.c:1331
>>  kvm_vm_release+0x43/0x50 virt/kvm/kvm_main.c:1354
>>  __fput+0x418/0xa50 fs/file_table.c:512
>>  task_work_run+0x1d9/0x270 kernel/task_work.c:233
>>  exit_task_work include/linux/task_work.h:40 [inline]
>>  do_exit+0x73a/0x2360 kernel/exit.c:1009
>>  do_group_exit+0x22d/0x2f0 kernel/exit.c:1152
>>  get_signal+0x121b/0x12c0 kernel/signal.c:3046
>>  arch_do_signal_or_restart+0xbb/0x860 arch/x86/kernel/signal.c:337
>>  __exit_to_user_mode_loop kernel/entry/common.c:66 [inline]
>>  exit_to_user_mode_loop+0x10e/0x770 kernel/entry/common.c:101
>>  __exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
>>  syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:230 [inline]
>>  syscall_exit_to_user_mode include/linux/entry-common.h:336 [inline]
>>  do_syscall_64+0x328/0x520 arch/x86/entry/syscall_64.c:89
>>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>> RIP: 0033:0x7fe3a1f5e90e
>> RSP: 002b:00007fe3a2e23f58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e6
>> RAX: fffffffffffffdfc RBX: 00007fe3a2e246c0 RCX: 00007fe3a1f5e90e
>> RDX: 00007fe3a2e23fb0 RSI: 0000000000000000 RDI: 0000000000000000
>> RBP: 00007fe3a2035024 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
>> R13: 00007fe3a2226308 R14: 00007fe3a2226270 R15: 00007fe3a234fa48
>>  </TASK>
>>
>>
>> ---
>> 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 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

-- 
Thanks,
Ye Liu