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
| ||
|
Date: Wed, 15 Jan 2020 08:03:45 +0800 From: Jiaxun Yang <jiaxun.yang@...goat.com> To: Paul Burton <paulburton@...nel.org> CC: linux-mips@...r.kernel.org, chenhc@...ote.com, paul.burton@...s.com, tglx@...utronix.de, jason@...edaemon.net, maz@...nel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] irqchip: mips-cpu: Remove eoi operation 于 2020年1月15日 GMT+08:00 上午7:30:25, Paul Burton <paulburton@...nel.org> 写到: >Hi Jiaxun, > >On Mon, Jan 13, 2020 at 06:12:51PM +0800, Jiaxun Yang wrote: >> The eoi opreation in mips_cpu_irq_controller caused chained_irq_enter >> falsely consider CPU IP interrupt as a FastEOI type IRQ. So the >interrupt >> won't be masked during in handler. Which might lead to spurious >interrupt. >> >> Thus we simply remove eoi operation for mips_cpu_irq_controller, >> >> Signed-off-by: Jiaxun Yang <jiaxun.yang@...goat.com> >> --- >> drivers/irqchip/irq-mips-cpu.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/drivers/irqchip/irq-mips-cpu.c >b/drivers/irqchip/irq-mips-cpu.c >> index 95d4fd8f7a96..0ad7f1f9a58b 100644 >> --- a/drivers/irqchip/irq-mips-cpu.c >> +++ b/drivers/irqchip/irq-mips-cpu.c >> @@ -55,7 +55,6 @@ static struct irq_chip mips_cpu_irq_controller = { >> .irq_mask = mask_mips_irq, >> .irq_mask_ack = mask_mips_irq, >> .irq_unmask = unmask_mips_irq, >> - .irq_eoi = unmask_mips_irq, >> .irq_disable = mask_mips_irq, >> .irq_enable = unmask_mips_irq, >> }; > >This one scares me; something doesn't seem right. The irq_eoi (née eoi) >callback was first added way back in commit 1417836e81c0 ("[MIPS] use >generic_handle_irq, handle_level_irq, handle_percpu_irq"). The commit >message there states that the motivation was to allow use of >handle_percpu_irq(), and indeed handle_percpu_irq() does: > > irq_ack() (ie. mask) > invoke the handler(s) > irq_eoi() (ie. unmask) > >By removing the irq_eoi callback I don't see how we'd ever unmask the >interrupt again..? Hi Paul, Sorry I didn't discover that by myself as all of my drivers are using chained handler. So how should we deal with the chained case? Probably we need a check in percpu IRQ handler to determine whether it's or not level type? > >Thanks, > Paul -- Jiaxun Yang
Powered by blists - more mailing lists