From nobody Thu Apr 2 19:02:18 2026 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BFF4B2ECE86 for ; Thu, 12 Feb 2026 11:41:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770896505; cv=none; b=lDK3u0r3Q79A/l7x7/KEavFf8YKZugm5Nyc0RwEe9F+r0Qzw1Apo/K5JGzgO9QAlyYNESF4PT0Qv8roNY+RotibURESYSZcHnz+JxZ+nipmaAHYapasnluiW4X2Ba62th1GcuDojLRVNhxjSnJmQtMNOEDzTEak21Jcw4zgHbCE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770896505; c=relaxed/simple; bh=AGk2paA2g5qqy6lgWK7mD4k7IhSy+ZrqoEbm9IJTKJA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=akJxFiYVYEYF9TYFp22JrlE0f29yif/ZiouymMZSizslWmpLMRd/yvCnMhfvlA8fJeUrRVcQBshq3aw4wAdd74qH4bzsfVj8e2GeGJshZ7uY64R1GC/z8+EmBqweB7O24wmNmq+sLzQw4lnPwLPjQGNvW/OXObUiDmJfn8ZzcQA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=E7WTjDT/; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=0voUlkdg; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="E7WTjDT/"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="0voUlkdg" From: Nam Cao DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1770896496; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=1xbsh6Z18XgLpEVhl943YbQBKoHtlngksvhjy78Lq7A=; b=E7WTjDT/+RLI5EYNgw9AIIF/f0sDGk/+olMBrAdyKzMIMibJ9Mhg3QKcWyuBaE9NKahORF DousRcOROnp3X9LMKs2sz1lYO9F409dKAEUJwCNFXe4iepUfhImz96F1pJmg+LDJEOopdU ZO4tNxH6SOWcUrXZA6tibZzuPsq8Qexm2bZZ/AaD/IZ6ZbYlcI+RPVpxmPcAhQ36vaK/W5 s2es1aSajp1BJavEFk4KQjycFyjdDU9QMDQT9e0fnXrpPc6Ltqjb+QBscbpjLr3uwNlcYc QVh+N07Qbti2d2IvfsIjxvf4PprsRK9PYf0d8D6OaAl7vOWLJFa0WjtLZKjahQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1770896496; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=1xbsh6Z18XgLpEVhl943YbQBKoHtlngksvhjy78Lq7A=; b=0voUlkdguKHaSNq5HfWeenUIIkeRaeVyOsrDZ4CBjZVNz8kI6QjNfkxth3pB2jo9V8R2As XUKdzQUGzd/jaUCw== To: Thomas Gleixner , Paul Walmsley , Samuel Holland , Marc Zyngier , Anup Patel , linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Cc: Nam Cao Subject: [PATCH] irqchip/sifive-plic: Fix frozen interrupt due to affinity setting Date: Thu, 12 Feb 2026 12:41:25 +0100 Message-ID: <20260212114125.3148067-1-namcao@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" PLIC ignores interrupt completion message for disabled interrupt, explained by the specification: The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that is currently enabled for the target, the completion is silently ignored. This caused problem in the past, because an interrupt can be disabled while still being handled and plic_irq_eoi() had no effect. That was fixed by checking if the interrupt is disabled, and if so enable it, before sending the completion message. That check is done with irqd_irq_disabled(). However, that is not sufficient because the enable bit for the handling hart can be zero despite irqd_irq_disabled(d) being false. This can happen when affinity setting is changed while a hart is still handling the interrupt. This problem is easily reproducible by dumping a large file to uart (which generates lots of interrupts) and at the same time keep changing the uart interrupt's affinity setting. The uart port becomes frozen almost jnstantly. Fix by checking PLIC's enable bit instead of irqd_irq_disabled(). Fixes: cc9f04f9a84f ("irqchip/sifive-plic: Implement irq_set_affinity() for= SMP host") Signed-off-by: Nam Cao --- drivers/irqchip/irq-sifive-plic.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive= -plic.c index 210a57959637..1565aab895bc 100644 --- a/drivers/irqchip/irq-sifive-plic.c +++ b/drivers/irqchip/irq-sifive-plic.c @@ -164,8 +164,13 @@ static void plic_irq_disable(struct irq_data *d) static void plic_irq_eoi(struct irq_data *d) { struct plic_handler *handler =3D this_cpu_ptr(&plic_handlers); + u32 __iomem *reg; + bool enabled; + + reg =3D handler->enable_base + (d->hwirq / 32) * sizeof(u32); + enabled =3D readl(reg) & BIT(d->hwirq % 32); =20 - if (unlikely(irqd_irq_disabled(d))) { + if (unlikely(!enabled)) { plic_toggle(handler, d->hwirq, 1); writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM); plic_toggle(handler, d->hwirq, 0); --=20 2.47.3