[Kernel Bug] BUG: soft lockup in kfree_rcu_monitor

[Longxing Li]

Dear Linux kernel developers and maintainers,

We would like to report a new kernel bug found by our tool. BUG: soft
lockup in kfree_rcu_monitor. Details are as follows.

Kernel commit: v7.0.6
Kernel config: see attachment
report: see attachment
C repro and Syz repro: see attachment

We are currently analyzing the root cause. We will provide further
updates in this thread as soon as we have more information.

Best regards,
Longxing Li

==================================================================
https://drive.google.com/file/d/1Bx2unEf-QntjVi8g6Zw7QNO6OP4cjGO_/view?usp=drive_link

https://drive.google.com/file/d/1Rqp_YWdi2uAcO7O8plg5k0NWxulZzoVu/view?usp=drive_link

https://drive.google.com/file/d/1nByyr16htns6Fy46FecT2lNzlogiK6e2/view?usp=drive_link

https://drive.google.com/file/d/1tJn4jOqAoXxROTevNlotQOefVn1FqS3t/view?usp=drive_link

[Harry Yoo]

On 6/9/26 8:46 PM, Longxing Li wrote:
> Dear Linux kernel developers and maintainers,

Hi Longxing,

> We would like to report a new kernel bug found by our tool. BUG: soft
> lockup in kfree_rcu_monitor. Details are as follows.
>
> Kernel commit: v7.0.6
> Kernel config: see attachment
> report: see attachment
> C repro and Syz repro: see attachment
>
> We are currently analyzing the root cause. We will provide further
> updates in this thread as soon as we have more information.
>
> Best regards,
> Longxing Li

Thanks for reporting the lockup.

In repro.report.txt:
> watchdog: BUG: soft lockup - CPU#0 stuck for 155s! [kworker/u4:4:68]
> Modules linked in:
> irq event stamp: 301450
> hardirqs last enabled at (301449): [<ffffffff8b7e2918>] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:178 [inline]
> hardirqs last enabled at (301449): [<ffffffff8b7e2918>] _raw_spin_unlock_irqrestore+0x58/0x70 kernel/locking/spinlock.c:194
> hardirqs last disabled at (301450): [<ffffffff8b7b288f>] sysvec_apic_timer_interrupt+0xf/0xc0 arch/x86/kernel/apic/apic.c:1056
> softirqs last enabled at (297862): [<ffffffff86641c3f>] rcu_lock_release include/linux/rcupdate.h:322 [inline]
> softirqs last enabled at (297862): [<ffffffff86641c3f>] rcu_read_unlock_bh include/linux/rcupdate.h:921 [inline]
> softirqs last enabled at (297862): [<ffffffff86641c3f>] mod_peer_timer+0x16f/0x2c0 drivers/net/wireguard/timers.c:38
> softirqs last disabled at (297856): [<ffffffff86641ae8>] local_bh_disable include/linux/bottom_half.h:20 [inline]
> softirqs last disabled at (297856): [<ffffffff86641ae8>] rcu_read_lock_bh include/linux/rcupdate.h:903 [inline]
> softirqs last disabled at (297856): [<ffffffff86641ae8>] mod_peer_timer+0x18/0x2c0 drivers/net/wireguard/timers.c:34
> CPU: 0 UID: 0 PID: 68 Comm: kworker/u4:4 Not tainted 7.0.6 #1 PREEMPT(full)
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> Workqueue: kvfree_rcu_reclaim kfree_rcu_monitor
> RIP: 0010:__rcu_read_unlock+0x10e/0x660 kernel/rcu/tree_plugin.h:443
> Code: 00 fc ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 e4 01 00 00 8b 83 c4 04 00 00 <3d> ff ff ff 3f 0f 87 b8 01 00 00 5b 5d 41 5c 41 5d 41 5e c3 cc cc
> RSP: 0018:ffffc90000bf76d8 EFLAGS: 00000246
> RAX: 0000000000000000 RBX: ffff88801f2d4b80 RCX: ffffc90000bf76c4
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88801f2d5044
> RBP: ffff88801f2d4b80 R08: ffffffff916123aa R09: ffffc90000bf7ad0
> R10: 00000000000129e8 R11: 00000000000a7f57 R12: ffff88801f2d4b80
> R13: ffffc90000bf7778 R14: ffffc90000bf7ad8 R15: ffffc90000bf77ac
> FS: 0000000000000000(0000) GS:ffff888097781000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f763b9aee00 CR3: 000000000e398000 CR4: 0000000000752ef0
> PKRU: 55555554
> Call Trace:
> <TASK>
> rcu_read_unlock include/linux/rcupdate.h:883 [inline]
> class_rcu_destructor include/linux/rcupdate.h:1193 [inline]
> unwind_next_frame+0x3bb/0x20c0 arch/x86/kernel/unwind_orc.c:495
> arch_stack_walk+0x86/0xf0 arch/x86/kernel/stacktrace.c:25
> stack_trace_save+0x8e/0xc0 kernel/stacktrace.c:122
> kasan_save_stack+0x24/0x50 mm/kasan/common.c:57
> kasan_save_track+0x14/0x30 mm/kasan/common.c:78
> kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584
> poison_slab_object mm/kasan/common.c:253 [inline]
> __kasan_slab_free+0x61/0x80 mm/kasan/common.c:285
> kasan_slab_free include/linux/kasan.h:235 [inline]
> slab_free_hook mm/slub.c:2685 [inline]
> slab_free_freelist_hook mm/slub.c:2714 [inline]
> slab_free_bulk mm/slub.c:6206 [inline]
> kmem_cache_free_bulk mm/slub.c:7010 [inline]
> kmem_cache_free_bulk+0x348/0x6b0 mm/slub.c:6989
> kfree_bulk include/linux/slab.h:823 [inline]
> kvfree_rcu_bulk+0x179/0x190 mm/slab_common.c:1502

Hmm, I'm not convinced that this is a bug in kvfree_rcu...

It's probably 1) there is a cycle in the slab freelist due to double
free (unlikely, the config has DEBUG_OBJECTS_RCU_HEAD and KASAN), or
2) it is not an infinite loop and it is just that there are so manydebug
configs so that freeing about about 500 objects takes quite long...

But we don't have enough data to conclude.

Could you please measure how long does kvfree_rcu_bulk() take per
object?

e.g.) by measuring statistics of
(time spent in kvfree_rcu_bulk()) / bnode->nr_records

> kvfree_rcu_drain_ready mm/slab_common.c:1704 [inline]
> kfree_rcu_monitor+0x180/0x2a0 mm/slab_common.c:1777
> process_one_work+0x9de/0x1c60 kernel/workqueue.c:3288
> process_scheduled_works kernel/workqueue.c:3371 [inline]
> worker_thread+0x693/0xeb0 kernel/workqueue.c:3452
> kthread+0x38d/0x4a0 kernel/kthread.c:436
> ret_from_fork+0x942/0xe50 arch/x86/kernel/process.c:158
> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> </TASK>

>
> ==================================================================
> https://drive.google.com/file/d/1Bx2unEf-QntjVi8g6Zw7QNO6OP4cjGO_/view?usp=drive_link
>
> https://drive.google.com/file/d/1Rqp_YWdi2uAcO7O8plg5k0NWxulZzoVu/view?usp=drive_link
>
> https://drive.google.com/file/d/1nByyr16htns6Fy46FecT2lNzlogiK6e2/view?usp=drive_link
>
> https://drive.google.com/file/d/1tJn4jOqAoXxROTevNlotQOefVn1FqS3t/view?usp=drive_link

--
Cheers,
Harry / Hyeonggon