| 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, 24 Sep 2008 00:01:57 +0530 From: "Singaravelan Nallasellan" <singaravelann@...il.com> To: linux-kernel@...r.kernel.org Subject: Interrupt handler latency and Interrupt handling issues I have an issue in determining the source of the interrupt due to the latency to access the register. The driver needs to send an read request to another kernel driver. The other driver will use an Indirect IO read to through an IO port. It will could also potentially generate interrupt. It will lead to the latency issues in the interrupt handler. The driver may not be able to realiably identify the source of the interrupt before coming out of the IRQ handler if it has to come out the handler within a letency period. Because of this, The driver will not be able to say IRQ handled before coming out of the handler. If the driver says IRQ handled assuming that the interrupt belongs to it, it could also cause conflict with the other interrupt handler registered for the same interrupt. I am planning to say that IRQ handled in the Interrupt handler and schedule a work queue to handle the identification and handling. Does anybody see issues here? Are there any better mechanism to handle this case? Is there any latency requirements from the kernel? How much is the tolerable latency for the interrupt handlers? Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists