linux-kernel - Long playing threaded interrupt handlers

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-next>] [day] [month] [year] [list]

Message-ID: <20100602070922.GC3713@core.coreip.homeip.net>
Date:	Wed, 2 Jun 2010 00:09:23 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Long playing threaded interrupt handlers

HI Thomas,

The threaded IRQ infrastructure that went into the kernel is extremely
helpful, however in the input land there are quite a few devices that
require polling after an IRQ has been raised.

Currently most such drivers, instead of threaded interrupts, still use
[delayed] work to do the polling, and still face the issue of shutting
down interrupt and scheduled work in a raceless way leaving irq enable
counter balanced. Is it allowed to have threaded ISR execute for
extended a amount of time, and do the required polling, provided that
ISR does certain checks to finish promply in case when we unbind the
driver or try to suspend the device?

Thanks.

-- 
Dmitry
--
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/