Re: [PATCH v2 4/4] irqchip/gicv3: Add workaround for FUJITSU-MONAKA erratum E#030003

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] irqchip/gic-v3: IPI via GICR_ISPENDR0 targets sleeping redistributor
- [High] irqchip/gicv3: missing NULL check on rd_base causes IPI sender crash
--

commit 98989a1fb6fe6471377f9b9c4a24e0097c1639a3
Author: Kohei Enju <enju.kohei@fujitsu.com>

irqchip/gicv3: Add workaround for FUJITSU-MONAKA erratum E#030003

This patch works around a FUJITSU-MONAKA erratum where SGIs are lost if an
SGI generation races with CPU interface processing. It addresses the issue
by bypassing the affected system registers and directly writing to the target
CPU's GICR_ISPENDR0 over MMIO.

> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
[ ... ]
> @@ -1386,6 +1391,17 @@ static void gic_ipi_send_mask(struct irq_data *d, const struct cpumask *mask)
>  	 */
>  	dsb(ishst);
>  
> +	if (static_branch_unlikely(&gic_fujitsu_030003_erratum)) {
> +		for_each_cpu(cpu, mask) {
> +			void __iomem *base = gic_data_rdist_sgi_base_cpu(cpu);

[Severity: High]
Could this cause a fatal page fault on the CPU sending the IPI if the target
CPU failed to initialize its redistributor?

If a secondary CPU fails to initialize its GIC redistributor due to a buggy
ACPI MADT or missing DT entry, rd_base remains NULL. However, the CPU can
still come online because gic_starting_cpu() returns 0 on failure.

When another CPU later broadcasts an IPI, this workaround will derive base
from a NULL rd_base, resulting in an unmapped address (0x10000). The sender
CPU will then crash when attempting the writel_relaxed().

Should we validate that the target CPU actually has an initialized
redistributor base before bypassing the architected SGI system registers?

> +
> +			writel_relaxed(BIT(d->hwirq), base + GICR_ISPENDR0);

[Severity: High]
Is it safe to write to a target CPU's GICR_ISPENDR0 directly over MMIO when
that CPU might be in deep idle?

During deep idle, such as via PSCI, the target CPU's redistributor is put
to sleep (ProcessorSleep=1 either via gic_cpu_pm_notifier or firmware).
According to the GICv3 architecture, writing to a redistributor register
(other than GICR_WAKER or GICR_TYPER) when ProcessorSleep=1 is constrained
unpredictable.

Normal kernel operations, like the scheduler sending smp_send_reschedule()
to an idle CPU, will hit this path. If the hardware ignores the write, the
IPI is dropped, which can lead to deadlocks in smp_call_function() or lost
wakeups.

> +		}
> +
> +		dsb(st);
> +		return;
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-monaka-fix-for-upstream-v2-0-fc7ede7f9f48@fujitsu.com?part=4