[syzbot] [virt?] INFO: trying to register non-static key in stats_request (2)

[syzbot] [virt?] INFO: trying to register non-static key in stats_request (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    8d3ae59288f1 Linux 7.2
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10240679580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=4c9eb8e593cf8c5c
dashboard link: https://syzkaller.appspot.com/bug?extid=13df72e0dc4be5c62215
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/cd49b631c498/disk-8d3ae592.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/05d3ad83c130/vmlinux-8d3ae592.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3a2efa4a6769/bzImage-8d3ae592.xz

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

INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 0 UID: 0 PID: 20235 Comm: irq/10-virtio2 Tainted: G             L      syzkaller #0 PREEMPT_{RT,(full)} 
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984
 register_lock_class+0xcc/0x2e0 kernel/locking/lockdep.c:1299
 __lock_acquire+0xab/0x2ce0 kernel/locking/lockdep.c:5112
 lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5868
 rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56
 spin_lock include/linux/spinlock_rt.h:45 [inline]
 start_wakeup_event drivers/virtio/virtio_balloon.c:150 [inline]
 stats_request+0xa5/0x1f0 drivers/virtio/virtio_balloon.c:435
 vring_interrupt+0x408/0x680 drivers/virtio/virtio_ring.c:3297
 vp_vring_interrupt drivers/virtio/virtio_pci_common.c:92 [inline]
 vp_interrupt+0x183/0x200 drivers/virtio/virtio_pci_common.c:123
 irq_thread_fn kernel/irq/manage.c:1143 [inline]
 irq_forced_thread_fn+0x98/0x120 kernel/irq/manage.c:1165
 irq_thread+0x455/0x690 kernel/irq/manage.c:1271
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </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

Re: [syzbot] [virt?] INFO: trying to register non-static key in stats_request (2)

[David Hildenbrand (Arm)]

On 8/22/26 02:11, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    8d3ae59288f1 Linux 7.2
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10240679580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=4c9eb8e593cf8c5c
> dashboard link: https://syzkaller.appspot.com/bug?extid=13df72e0dc4be5c62215
> compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
> 

virtio-balloon in an RT kernel/environment, unlikely in pactice ... :)

> Unfortunately, I don't have any reproducer for this issue yet.
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/cd49b631c498/disk-8d3ae592.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/05d3ad83c130/vmlinux-8d3ae592.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/3a2efa4a6769/bzImage-8d3ae592.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+13df72e0dc4be5c62215@syzkaller.appspotmail.com
> 
> INFO: trying to register non-static key.
> The code is fine but needs lockdep annotation, or maybe
> you didn't initialize this object before use?
> turning off the locking correctness validator.
> CPU: 0 UID: 0 PID: 20235 Comm: irq/10-virtio2 Tainted: G             L      syzkaller #0 PREEMPT_{RT,(full)} 
> Tainted: [L]=SOFTLOCKUP
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
> Call Trace:
>  <TASK>
>  dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
>  assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984
>  register_lock_class+0xcc/0x2e0 kernel/locking/lockdep.c:1299
>  __lock_acquire+0xab/0x2ce0 kernel/locking/lockdep.c:5112
>  lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5868
>  rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56
>  spin_lock include/linux/spinlock_rt.h:45 [inline]
>  start_wakeup_event drivers/virtio/virtio_balloon.c:150 [inline]
>  stats_request+0xa5/0x1f0 drivers/virtio/virtio_balloon.c:435


I don't really understand what's happening here, Is the register_lock_class()
trying to reguster a non-static key?

I don't immediately see how virtio-balloon is doing something odd here, all it
does is a spin_lock_irqsave(&vb->wakeup_lock, flags), that was earlier
initialized with spin_lock_init(&vb->wakeup_lock), before the device was ready.

-- 
Cheers,

David

[PATCH] virtio_balloon: initialize wakeup_lock before virtqueues are set up

[Mingbing Zhai]

Since c578123e63da ("virtio_balloon: Treat stats requests as wakeup
events") the stats_request() virtqueue callback takes vb->wakeup_lock
via start_wakeup_event().  init_vqs() registers that callback and even
primes and kicks the stats queue, so the lock is reachable from irq
context as soon as init_vqs() returns, long before the driver sets
DRIVER_OK: vring_interrupt() dispatches to the callback without any
DRIVER_OK check unless CONFIG_VIRTIO_HARDEN_NOTIFICATION is set, and
that option depends on BROKEN.  syzbot hit it from a threaded irq:

  INFO: trying to register non-static key in stats_request
  ...
  assign_lock_key
  register_lock_class
  lock_acquire
  rt_spin_lock
  start_wakeup_event drivers/virtio/virtio_balloon.c:150 [inline]
  stats_request drivers/virtio/virtio_balloon.c:435

The lock is only initialized near the end of virtballoon_probe(),
after init_vqs() and several steps that can still fail and unwind
through del_vqs(), where a racing interrupt still finds the callback
registered.  Until then it is whatever kzalloc() left in vb: lockdep
complains about the unregistered lock class, and wakeup_signal_mask
and processing_wakeup_event get updated from irq context while probe
is still running.

The rt_spin_lock() in the report is just spin_lock() on PREEMPT_RT;
any PROVE_LOCKING build takes the same path.

stop_update_lock(), which the same callback also acquires, is already
initialized before init_vqs(); do the same for wakeup_lock.

Fixes: c578123e63da ("virtio_balloon: Treat stats requests as wakeup events")
Reported-by: syzbot+13df72e0dc4be5c62215@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=13df72e0dc4be5c62215
Signed-off-by: Mingbing Zhai <zhaimingbing@cmss.chinamobile.com>
---

Hi David,

On 24.08.26 14:57, David Hildenbrand (Arm) wrote:
> I don't really understand what's happening here, Is the
> register_lock_class() trying to reguster a non-static key?

It is: the wakeup_lock that stats_request() ends up taking at that
point hasn't been run through spin_lock_init() yet.

> I don't immediately see how virtio-balloon is doing something odd
> here, all it does is a spin_lock_irqsave(&vb->wakeup_lock, flags),
> that was earlier initialized with spin_lock_init(&vb->wakeup_lock),
> before the device was ready.

Right, the lock is initialized before virtio_device_ready().  But if
I follow correctly, stats_request() can already fire once init_vqs()
registers it as the stats virtqueue callback, some 100 lines before
the spin_lock_init().  I also don't see anything on the guest side
gating the IRQ: vring_interrupt() calls the callback without any
DRIVER_OK check unless CONFIG_VIRTIO_HARDEN_NOTIFICATION (which
depends on BROKEN).  So a device raising the interrupt while probe is
still running would take the zero-initialized lock.

> virtio-balloon in an RT kernel/environment, unlikely in pactice ... :)

I don't think it is RT-specific, though: rt_spin_lock() is just what
spin_lock() compiles to on PREEMPT_RT, so any PROVE_LOCKING build
should hit the same register_lock_class() path on that lock.

stop_update_lock(), which the same callback takes first, is already
initialized before init_vqs(); the patch below does the same for
wakeup_lock.  Does that look reasonable?

 drivers/virtio/virtio_balloon.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index ab3e3d887e..8c1b47ec17 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -942,6 +942,7 @@ static int virtballoon_probe(struct virtio_device *vdev)
 	INIT_WORK(&vb->update_balloon_stats_work, update_balloon_stats_func);
 	INIT_WORK(&vb->update_balloon_size_work, update_balloon_size_func);
 	spin_lock_init(&vb->stop_update_lock);
+	spin_lock_init(&vb->wakeup_lock);
 	mutex_init(&vb->balloon_lock);
 	init_waitqueue_head(&vb->acked);
 	vb->vdev = vdev;
@@ -1049,8 +1050,6 @@ static int virtballoon_probe(struct virtio_device *vdev)
 			goto out_unregister_oom;
 	}
 
-	spin_lock_init(&vb->wakeup_lock);
-
 	/*
 	 * The virtio balloon itself can't wake up the device, but it is
 	 * responsible for processing wakeup events passed up from the transport
-- 
2.53.0.windows.1

Re: [PATCH] virtio_balloon: initialize wakeup_lock before virtqueues are set up

[sashiko-bot]

> Since c578123e63da ("virtio_balloon: Treat stats requests as wakeup
> events") the stats_request() virtqueue callback takes vb->wakeup_lock
> via start_wakeup_event().  init_vqs() registers that callback and even
> primes and kicks the stats queue, so the lock is reachable from irq
> context as soon as init_vqs() returns, long before the driver sets
> DRIVER_OK: vring_interrupt() dispatches to the callback without any
> DRIVER_OK check unless CONFIG_VIRTIO_HARDEN_NOTIFICATION is set, and
> that option depends on BROKEN.  syzbot hit it from a threaded irq:
> 
>   INFO: trying to register non-static key in stats_request
>   ...
>   assign_lock_key
>   register_lock_class
>   lock_acquire
>   rt_spin_lock
> [ ... ]
> 
> Fixes: c578123e63da ("virtio_balloon: Treat stats requests as wakeup events")
> Reported-by: syzbot+13df72e0dc4be5c62215@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=13df72e0dc4be5c62215
> Signed-off-by: Mingbing Zhai <zhaimingbing@cmss.chinamobile.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016025429.901-1-zhaimingbing@cmss.chinamobile.com?part=1