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

Message-ID: <20091007102836.GA27860@flint.arm.linux.org.uk>
Date:	Wed, 7 Oct 2009 11:28:36 +0100
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	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, Oct 07, 2009 at 12:07:56PM +0200, Uwe Kleine-König wrote:
> Hallo,
> 
> I'm seeing an imx31 (ARCH=arm) based system failing to boot .31.2-rt13.
> 
> The reason is that the irq for the ethernet device is level triggered,
> but the handler for that interrupt is handle_edge_irq.

There's nothing wrong with that with the conventional interrupt handling
scheme.

> As the handler is threaded with PREEMPT_RT=y, the irq is only acked but
> neither masked (as it is believed to be an edge irq) nor handled.  This
> stucks the machine as the irq is still active.

Actually, the problem is that I misnamed the edge/level handlers.
What follows here is the non-RT case.

Really, what the two are about is that the level handler is there for
interrupt controllers which behave in a good way - in other words, for
level-based inputs and for edge-based inputs which "remember" new
transitions while the input is masked.

The edge handler is for edge-based inputs where the controller does not
remember transitions with the input masked.

Forcing people to use the edge handler all the time for edge based inputs
is highly sub-optimal - it means greater interrupt load since the input
is left unmasked.

So really, the choice of the handler should be determined by how the
hardware behaves, and not by the input type requested.

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.

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.)

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.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
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/