Re: [bug report] Potential deadlock bug in 'drivers/misc/vmw_balloon.c', between 'vmballoon_work()' and 'vmci_interrupt()'

[Jerrin Shaji George]

On Fri, Apr 24, 2026 at 1:38 AM Ginger <ginger.jzllee@xxxxxxxxx> wrote:
> My research-based static analyzer found a potential deadlock bug
> within the 'drivers/misc' subsystem, more specifically, in
> 'drivers/misc/vmw_balloon.c'.
>
> Potential concurrent triggering executions:
> T0:
> vmci_interrupt [t1]
>         --> vmci_process_bitmap
>              --> vmci_dbell_scan_notification_entries
>                   --> dbell_fire_entries
>                        --> spin_lock_bh(&vmci_doorbell_it.lock); [t2]
>
> T1:
> vmballoon_work
>         --> vmballoon_reset
>              --> vmballoon_vmci_init
>                   --> vmci_doorbell_create
>                       --> dbell_index_table_add
>                            --> spin_lock_bh(&vmci_doorbell_it.lock); [t0]
>
> T1 runs in the normal process context and does not disable hardware
> irqs in acquiring the spin lock.
> If T0 (i.e., the hard irq context) occurs after T1 acquires the lock

Thanks for sending the bug report. I took a look. Looks like this is a
false positive report from your tool. vmci_interrupt runs in a threaded
interrupt context. When T1 runs it disables preemption. So if a hardware
interrupt fires later and wakes up the vmci_interrupt thread, it cannot
interrupt T1 on the same CPU. Hence I don't see a deadlock issue here.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature