Re: [bug report] Potential deadlock bug in 'drivers/gpu/drm/vmwgfx/vmwgfx_irq.c', between 'vmw_thread_fn()' and 'vmw_cmdbuf_header_free()'

[Ginger]

On Fri, Apr 24, 2026 at 9:08 PM Ian Forbes <ian.forbes@xxxxxxxxxxxx> wrote:
>
> T0 is a threaded IRQ handler so it should not run in an IRQ context.
>

Thank you for the timely response and clarification.
Sorry I missed the point when filing the report, which was carelessly
neglected by the tool.
Thank you again for your time and consideration.

> On Fri, Apr 24, 2026 at 2:45 AM Ginger <ginger.jzllee@xxxxxxxxx> wrote:
>>
>> Dear Linux kernel maintainers,
>>
>> My research-based static analyzer found a potential deadlock bug
>> within the 'drivers/gpu/drm/vmwgfxl' subsystem, more specifically, in
>> 'drivers/gpu/drm/vmwgfx/vmwgfx_irq.c'.
>> This deadlock potentially occurs with the involvement of hard irq.
>>
>> Kernel version: long-term kernel v6.18.9
>>
>> Potential concurrent triggering executions:
>> T0:
>> vmw_thread_fn[t1]
>>        --> vmw_cmdbuf_irqthread
>>               --> spin_lock(&man->lock); [t2]
>>
>> T1:
>> vmw_cmdbuf_header_free
>>     --> spin_lock(&man->lock) [t0]
>>
>> T1 does not disable hardware irqs in acquiring the spin lock. If T0
>> (i.e., the hard irq context) occurs after T1 acquires the lock and
>> both happen within the same CPU, then T0 will not proceed because it
>> cannot hold the spin lock that has already been possessed by T1, yet
>> T1 cannot proceed because the hard irq runs disables preempts.
>>
>> Thank you for your time and consideration.
>>
>> Sincerely,
>> Ginger