Re: [PATCH v2 6/6] KVM: arm64: vgic-v3: Indicate vgic_put_irq() may take LPI xarray lock

[Zenghui Yu <yuzenghui@huawei.com>]

On 2025/11/6 8:58, Oliver Upton wrote:
> On Wed, Nov 05, 2025 at 04:46:59PM -0800, Oliver Upton wrote:
> > Hey,
> >
> > On Wed, Nov 05, 2025 at 10:28:04AM +0000, Marc Zyngier wrote:
> > > On Wed, 05 Nov 2025 09:37:10 +0000,
> > > Zenghui Yu <yuzenghui@huawei.com> wrote:
> > > >  Call trace:
> > > >   show_stack+0x18/0x24 (C)
> > > >   dump_stack_lvl+0x90/0xd0
> > > >   dump_stack+0x18/0x24
> > > >   print_usage_bug.part.0+0x29c/0x358
> > > >   mark_lock+0x6c0/0x960
> > > >   __lock_acquire+0xd4c/0x20fc
> > > >   lock_acquire+0x1c8/0x354
> > > >   vgic_put_irq+0x54/0x110
> > > >   vgic_its_inject_cached_translation+0x178/0x25c
> > > >   kvm_arch_set_irq_inatomic+0xac/0x124
> > >
> > > Right. This might_lock() is gross, and clearly doesn't do the right
> > > thing outside of direct injection of LPIs.
> > >
> > > I think we should drop it, but we should ensure that lpi_xa.xa_lock is
> > > never taken in interrupt context.
> > >
> > > Oliver, what do you think?
> >
> > It is possible (albeit improbable) that the last reference to an LPI gets
> > dropped here after injecting a cached translation. When that is the
> > case, vgic_put_irq() will take the xa_lock from an irq context.

IMO this is possible (with a really small possibility though) to happen.

> > So
> > I'd say the might_lock() here is valid.
> >
> > Zenghui, does reverting 982f31bbb5b0 ("KVM: arm64: vgic-v3: Don't require
> > IRQs be disabled for LPI xarray lock") make this go away?
> 
> Well, a bit more than that. Revert and add the diff below. Like I said
> in the original changelog, finding bugs for rare release paths is
> annoying and having a reliable way of causing an explosion when the
> calling context isn't right is a property I'd like to preserve.

The warning disappears with that.

Thanks,
Zenghui