linux-kernel - [PATCH AUTOSEL 6.16] irqchip/mvebu-gicp: Clear pending interrupts on init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-Id: <20250810165158.1888206-13-sashal@kernel.org>
Date: Sun, 10 Aug 2025 12:51:55 -0400
From: Sasha Levin <sashal@...nel.org>
To: patches@...ts.linux.dev,
	stable@...r.kernel.org
Cc: Elad Nachman <enachman@...vell.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Sasha Levin <sashal@...nel.org>,
	andrew@...n.ch,
	gregory.clement@...tlin.com,
	sebastian.hesselbarth@...il.com,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH AUTOSEL 6.16] irqchip/mvebu-gicp: Clear pending interrupts on init

From: Elad Nachman <enachman@...vell.com>

[ Upstream commit 3c3d7dbab2c70a4bca47634d564bf659351c05ca ]

When a kexec'ed kernel boots up, there might be stale unhandled interrupts
pending in the interrupt controller. These are delivered as spurious
interrupts once the boot CPU enables interrupts.

Clear all pending interrupts when the driver is initialized to prevent
these spurious interrupts from locking the CPU in an endless loop.

Signed-off-by: Elad Nachman <enachman@...vell.com>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Link: https://lore.kernel.org/all/20250803102548.669682-2-enachman@marvell.com
Signed-off-by: Sasha Levin <sashal@...nel.org>
---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees. Here's my
extensive analysis:

## Reasons for Backporting:

### 1. **Fixes a Real Bug Affecting Users**
The commit addresses a concrete issue where stale, unhandled interrupts
from before a kexec can cause spurious interrupts that lock the CPU in
an endless loop. This is a serious functionality bug that can prevent
systems from booting properly after kexec.

### 2. **Small and Contained Fix**
The change is minimal and surgical:
- Only adds 9 lines of functional code
- The fix is self-contained within the probe function
- Simply clears pending interrupts by writing to the
  GICP_CLRSPI_NSR_OFFSET register for all 64 possible interrupts
- Uses standard kernel APIs (ioremap/iounmap)

### 3. **Low Risk of Regression**
- The clearing operation only happens once during driver initialization
- If ioremap fails, it's handled gracefully with an error message but
  doesn't fail the probe
- The clearing loop writes to a register specifically designed for
  clearing interrupts (GICP_CLRSPI_NSR_OFFSET)
- This is a write-only operation that doesn't affect normal interrupt
  handling flow

### 4. **Follows Established Pattern**
Similar fixes for spurious/pending interrupts have been backported in
other interrupt controllers:
- commit 28e89cdac648 ("irqchip/renesas-rzv2h: Prevent TINT spurious
  interrupt") - marked with Cc: stable@...r.kernel.org
- commit 853a6030303f ("irqchip/renesas-rzg2l: Prevent spurious
  interrupts when setting trigger type")

### 5. **Critical for Kexec Functionality**
Kexec is an important feature for:
- Crash dump collection (kdump)
- Fast reboot scenarios
- System recovery
This fix ensures these use cases work reliably on Marvell platforms
using the GICP interrupt controller.

### 6. **No Architectural Changes**
The fix doesn't introduce:
- New features or capabilities
- Changes to existing APIs or interfaces
- Modifications to interrupt handling logic
- Any structural changes to the driver

### 7. **Clear Problem Statement**
The commit message clearly describes:
- The problem scenario (kexec with pending interrupts)
- The symptom (CPU locked in endless loop)
- The solution (clear all pending interrupts on init)

## Code Analysis:

The added code (lines 240-247 in the patched version):
```c
base = ioremap(gicp->res->start, gicp->res->end - gicp->res->start);
if (IS_ERR(base)) {
    dev_err(&pdev->dev, "ioremap() failed. Unable to clear pending
interrupts.\n");
} else {
    for (i = 0; i < 64; i++)
        writel(i, base + GICP_CLRSPI_NSR_OFFSET);
    iounmap(base);
}
```

This is a defensive programming approach that ensures system stability
without affecting normal operation, making it an ideal candidate for
stable backport.

 drivers/irqchip/irq-mvebu-gicp.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/irqchip/irq-mvebu-gicp.c b/drivers/irqchip/irq-mvebu-gicp.c
index d3232d6d8dce..fd85c845e015 100644
--- a/drivers/irqchip/irq-mvebu-gicp.c
+++ b/drivers/irqchip/irq-mvebu-gicp.c
@@ -177,6 +177,7 @@ static int mvebu_gicp_probe(struct platform_device *pdev)
 		.ops	= &gicp_domain_ops,
 	};
 	struct mvebu_gicp *gicp;
+	void __iomem *base;
 	int ret, i;
 
 	gicp = devm_kzalloc(&pdev->dev, sizeof(*gicp), GFP_KERNEL);
@@ -236,6 +237,15 @@ static int mvebu_gicp_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
+	base = ioremap(gicp->res->start, gicp->res->end - gicp->res->start);
+	if (IS_ERR(base)) {
+		dev_err(&pdev->dev, "ioremap() failed. Unable to clear pending interrupts.\n");
+	} else {
+		for (i = 0; i < 64; i++)
+			writel(i, base + GICP_CLRSPI_NSR_OFFSET);
+		iounmap(base);
+	}
+
 	return msi_create_parent_irq_domain(&info, &gicp_msi_parent_ops) ? 0 : -ENOMEM;
 }
 
-- 
2.39.5