Re: [PATCH] arm64: errata: Mitigate AmpereOne erratum AC03_CPU_57 and AC04_CPU_29

[Marc Zyngier <maz@kernel.org>]

On Fri, 10 Jul 2026 23:37:17 +0100,
sashiko-bot@kernel.org wrote:

[...]

> [Severity: High]
> This isn't a bug introduced by this patch, but does dropping irq->irq_lock
> between computing the LR snapshot and folding it create a race condition that
> loses concurrent virtual interrupts?
> 
> vgic_v3_deactivate() takes the lock, computes the snapshot, and then the
> scoped_guard ends:
> 
> scoped_guard(raw_spinlock, &irq->irq_lock) {
>     ...
>     lr = vgic_v3_compute_lr(vcpu, irq) & ~ICH_LR_ACTIVE_BIT;
> }
> 
> If a concurrent device injects an interrupt here via vgic_inject_irq() and
> sets irq->pending_latch = true, won't the subsequent call to
> vgic_v3_fold_lr(vcpu, lr) re-acquire the lock and evaluate the stale snapshot?
> 
> vgic_v3_fold_lr() would see !(val & ICH_LR_STATE) is true and execute:
> 
> if (irq->config == VGIC_CONFIG_LEVEL && !(val & ICH_LR_STATE))
>     irq->pending_latch = false;
> 
> Could this wipe out the newly arrived interrupt and cause guest devices to
> stall?

Having thought about it (yes, this is what the NSJ is for), my
conclusion is that this report is utter bollocks.

The clearing of the latch obviously only applies to level interrupts,
which can only be set by SW. The convention is that the Ack of a level
interrupt consumes the latched signal (SW can't distinguish it from a
device interrupt anyway).

A *device* interrupt sets irq->line_level, and can only be dropped by
the device itself, not by anything happening in the LR.

My conclusion is that Sashiko doesn't understand the GIC interrupt
life cycle, and is deeply confused by it. I'm shocked.

	M.

-- 
Jazz isn't dead. It just smells funny.