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: Tue, 25 Oct 2016 10:36:34 +0200 From: Mason <slash.tmp@...e.fr> To: Sebastian Frias <sf84@...oste.net>, Thomas Gleixner <tglx@...utronix.de> Cc: Marc Zyngier <marc.zyngier@....com>, Jason Cooper <jason@...edaemon.net>, LKML <linux-kernel@...r.kernel.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org> Subject: Re: Disabling an interrupt in the handler locks the system up On 25/10/2016 10:29, Sebastian Frias wrote: > On 10/24/2016 06:55 PM, Thomas Gleixner wrote: > >> On Mon, 24 Oct 2016, Mason wrote: >> >>> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device >>> makes the system lock-up disappear. >> >> The way how lazy irq disabling works is: >> >> 1) Interrupt is marked disabled in software, but the hardware is not masked >> >> 2) If the interrupt fires befor the interrupt is reenabled, then it's >> masked at the hardware level in the low level interrupt flow handler. > > Would you mind explaining what is the intention behind? > Because it does not seem obvious why there isn't a direct map between > "disable_irq*()" and "mask_irq()" I had a similar, but slightly different question: What is the difference between struct irq_chip's * @irq_shutdown: shut down the interrupt (defaults to ->disable if NULL) * @irq_disable: disable the interrupt * @irq_mask: mask an interrupt source (enable seems to default to unmask, but disable does not default to mask) Regards.
Powered by blists - more mailing lists