linux-kernel - Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

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: <3efb10970711290618v2bd93edfrbc53d9df4b73b33b@mail.gmail.com>
Date:	Thu, 29 Nov 2007 15:18:04 +0100
From:	"Remy Bohmer" <linux@...mer.net>
To:	"Russell King - ARM Linux" <linux@....linux.org.uk>
Cc:	"Steven Rostedt" <rostedt@...dmis.org>,
	"Daniel Walker" <dwalker@...sta.com>,
	RT <linux-rt-users@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"ARM Linux Mailing List" <linux-arm-kernel@...ts.arm.linux.org.uk>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Ingo Molnar" <mingo@...e.hu>
Subject: Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

Hello Russell,

> If people insist on adding the mask/unmask crap to it, the function
> might as well be deleted and be an alias for handle_level_IRQ.  Because
> that's _precisely_ what you lot are turning it into.

First, I want to make clear that I am just debugging a problem on RT
that does not exist on mainline, and I am trying to find a way to get
it solved nicely _on RT_, and preferable in a way that it works for
everybody with the least chance for regression.

I already mentioned that RT is doing masking in this code during
normal use, where the mainline kernel does not do this, **except** in
an error situation.

I also mentioned that there are 2 ways of solving it on RT:
1) do not do masking at all, (just as on mainline), and only mask it
when there is an error (just as on mainline)
2) Fix it by adding an unmask, which I proposed in my first patch, and
which others also did in their patches. (not knowing your opinion, as
I do know)

Still, I believe, that the fact if a interrupt **can** be masked is
not a reason to forbid the simple_irq type(), and surely does not make
it automatically a level type interrupt.
The interrupt type I talk about is actually edge triggered (the
interrupt triggers on _BOTH_ edges of the input-line), but there is no
way of 'acknowledging' the interrupt, which makes the edge type
handler unsuitable, and much too heavy.
As mentioned, this type of irq is never pending, and unmasking it will
never lead to get a interrupt request immediately; the interrupt that
occurs during the masked time, is just lost.

So, as far as I can tell , the type really used on at91 for the GPIO
stuff _is_ a simple_irq as you describe, but one that can be
masked/unmasked **in case of errors**. It should never be masked
during normal use.

So, I propose option 1 to solve it on RT, and thus to trigger Steven
to NACK my first patch. I will try and see if I can make it work
_without_ masking on RT (except in case of errors, just as in
mainline).
...and probably add some clear description about the purpose of
simple_irq, especially related to masking...

Do you agree on this Russell?

> Ah, and looking at the changes to the file, the addition of the mask
> and unmask was done by someone who didn't understand what this was
> trying to do.  So that change should be backed out.

Maybe he was trying to mask the irq during an error situation?

Kind regards,

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