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>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <162946648413.25758.10370643723543390409.tip-bot2@tip-bot2>
Date:   Fri, 20 Aug 2021 13:34:44 -0000
From:   "irqchip-bot for Sven Peter" <tip-bot2@...utronix.de>
To:     linux-kernel@...r.kernel.org
Cc:     Sven Peter <sven@...npeter.dev>, Hector Martin <marcan@...can.st>,
        Marc Zyngier <maz@...nel.org>, tglx@...utronix.de
Subject: [irqchip: irq/irqchip-next] irqchip/apple-aic: Fix irq_disable from
 within irq handlers

The following commit has been merged into the irq/irqchip-next branch of irqchip:

Commit-ID:     60a1cd10b222e004f860d14651e80089c77e8e6b
Gitweb:        https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/60a1cd10b222e004f860d14651e80089c77e8e6b
Author:        Sven Peter <sven@...npeter.dev>
AuthorDate:    Thu, 12 Aug 2021 12:09:42 +02:00
Committer:     Marc Zyngier <maz@...nel.org>
CommitterDate: Fri, 20 Aug 2021 14:32:33 +01:00

irqchip/apple-aic: Fix irq_disable from within irq handlers

When disable_irq_nosync for an interrupt is called from within its
interrupt handler, this interrupt is only marked as disabled with the
intention to mask it when it triggers again.
The AIC hardware however automatically masks the interrupt when it is read.
aic_irq_eoi then unmasks it again if it's not disabled *and* not masked.
This results in a state mismatch between the hardware state and the
state kept in irq_data: The hardware interrupt is masked but
IRQD_IRQ_MASKED is not set. Any further calls to unmask_irq will directly
return and the interrupt can never be enabled again.

Fix this by keeping the hardware and irq_data state in sync by unmasking in
aic_irq_eoi if and only if the irq_data state also assumes the interrupt to
be unmasked.

Fixes: 76cde2639411 ("irqchip/apple-aic: Add support for the Apple Interrupt Controller")
Signed-off-by: Sven Peter <sven@...npeter.dev>
Acked-by: Hector Martin <marcan@...can.st>
Signed-off-by: Marc Zyngier <maz@...nel.org>
Link: https://lore.kernel.org/r/20210812100942.17206-1-sven@svenpeter.dev
---
 drivers/irqchip/irq-apple-aic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-apple-aic.c b/drivers/irqchip/irq-apple-aic.c
index b8c06bd..6fc145a 100644
--- a/drivers/irqchip/irq-apple-aic.c
+++ b/drivers/irqchip/irq-apple-aic.c
@@ -226,7 +226,7 @@ static void aic_irq_eoi(struct irq_data *d)
 	 * Reading the interrupt reason automatically acknowledges and masks
 	 * the IRQ, so we just unmask it here if needed.
 	 */
-	if (!irqd_irq_disabled(d) && !irqd_irq_masked(d))
+	if (!irqd_irq_masked(d))
 		aic_irq_unmask(d);
 }
 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ