linux-kernel - Re: Using set_irq_handler in set_irq

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: <alpine.LFD.2.00.0910071245190.9428@localhost.localdomain>
Date:	Wed, 7 Oct 2009 12:47:56 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Russell King <rmk+lkml@....linux.org.uk>
cc:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>, linux-kernel@...r.kernel.org,
	linux-rt-users@...r.kernel.org,
	Sascha Hauer <s.hauer@...gutronix.de>
Subject: Re: Using set_irq_handler in set_irq_type callback?

On Wed, 7 Oct 2009, Russell King wrote:
> On Wed, Oct 07, 2009 at 12:07:56PM +0200, Uwe Kleine-König wrote:
> When it comes to RT and its thread-based interrupt model, the assumptions
> which these handlers were designed around are no longer true.  What is
> now required is a different handling philosophy - rather than leaving
> the interrupt-time decision about what to do with a signalled interrupt
> to the flow handler, it should be immediately ack'ed and disabled, and
> the interrupt thread scheduled.

That's what the code does at least for the level handler. When the
thread has run then the irq line is reenabled.
 
> It is then up to the interrupt thread to determine how to handle the
> interrupt - if it's really a level interrupt, then the interrupt thread
> has to call the handlers before re-enabling the input.  If it's edge
> based, the input has to be re-enabled before running the handlers (so
> that new edges received during the running of those handlers are
> recognised.)

That's exaclty how the RT code works :) 
 
> So, the technical aspects of handling of interrupts between the RT and
> non-RT cases are quite different, and I feel that we shouldn't be
> re-using the same flow handlers between the two cases.

Why not. It works perfectly fine except for the case where a level
type interrupt uses the edge handler :)

Thanks,

	tglx