Re: [PATCH 3/5] irqchip/gic-v5: Synchronize CPU interface disable
[email protected] Mon, 10 Aug 2026 10:54:39 +0000
| Newsgroups | dev.linux.lists.kvmarm,org.kernel.vger.kvm |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [High] This problem wasn't introduced by this patch, but it leaves critical architectural violations unaddressed due to a misunderstanding of ARM64 requirements (as noted in the commit message). Missing mandatory `isb()` instructions immediately after writing to control-plane system registers (`ICC_*_EL1`). The ARM64 architecture subsystem guidelines mandate that every write to a control-plane system register MUST be followed by an `isb()` as the very next instruction. The `isb()` synchronizes the local CPU pipeline; it does not wait for external interrupt delivery. The patch author explicitly omitted an `isb()` after writing to `SYS_ICC_CR0_EL1` in `gicv5_cpu_enable_interrupts()`, claiming 'interrupt delivery is asynchronous'. Furthermore, there are preexisting violations across multiple functions (`gicv5_cpu_enable_interrupts()`, `gicv5_ppi_priority_init()`, and `write_ppi_sysreg_s()`) where writes to `ICC_*_EL1` registers are batched with intervening instructions before an eventual `isb()`, or lack one entirely. -- --- Patch [3]: [PATCH 3/5] irqchip/gic-v5: Synchronize CPU interface disable --- commit 55c441d845df8718ca0aac7ff0ab6a4a351c19dc Author: Sascha Bischoff <[email protected]> irqchip/gic-v5: Synchronize CPU interface disable This commit adds a missing ISB instruction after the ICC_CR0_EL1 write in gicv5_cpu_disable_interrupts() to ensure interrupts are disabled before the function returns. Link: https://sashiko.dev/#/patchset/[email protected]?part=6 > Add an ISB after the ICC_CR0_EL1 write to ensure interrupts are > disabled before the function returns. No corresponding ISB is added > when enabling the interface, as interrupt delivery is asynchronous and > there is no obvious benefit to waiting for it. [Severity: High] This isn't a bug introduced by this patch, but does omitting the ISB leave the CPU pipeline in an undefined state? The ARM64 architecture requires an isb() immediately after writing to control-plane system registers like ICC_*_EL1 to synchronize the local CPU pipeline, not just to wait for external interrupt delivery. > diff --git a/drivers/irqchip/irq-gic-v5.c b/drivers/irqchip/irq-gic-v5.c > index e9d1795235a66..6a99c541b559b 100644 > --- a/drivers/irqchip/irq-gic-v5.c > +++ b/drivers/irqchip/irq-gic-v5.c > @@ -983,6 +983,7 @@ static void gicv5_cpu_disable_interrupts(void) > > cr0 = FIELD_PREP(ICC_CR0_EL1_EN, 0); > write_sysreg_s(cr0, SYS_ICC_CR0_EL1); > + isb(); > } > > static void gicv5_cpu_enable_interrupts(void) [Severity: High] This is a pre-existing issue, but should gicv5_cpu_enable_interrupts() and other related functions also be updated to include the mandatory isb() instructions? For example, in gicv5_cpu_enable_interrupts(), writes to registers like SYS_ICC_PPI_ENABLER0_EL1 and SYS_ICC_CR0_EL1 lack an immediate isb() after each write. Similarly, are the batched writes in gicv5_ppi_priority_init() and the state updates in write_ppi_sysreg_s() missing their required isb() synchronizations before returning? Placing a return instruction or intervening instructions before an isb() can cause the CPU to observe undefined pipeline state. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3