linux-kernel - Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a7fc5e43-34c2-a4e6-e0c5-1584f17fb024@denx.de>
Date:   Mon, 23 Mar 2020 20:04:23 +0100
From:   Marek Vasut <marex@...x.de>
To:     Marc Zyngier <maz@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>
Cc:     Alexandre Torgue <alexandre.torgue@...com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel@...r.kernel.org,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to
 gpio irq chip

On 2/20/20 10:17 AM, Marc Zyngier wrote:
> On 2020-02-20 09:04, Linus Walleij wrote:
>> On Wed, Feb 19, 2020 at 3:32 PM Alexandre Torgue
>> <alexandre.torgue@...com> wrote:
>>
>>> GPIO hardware block is directly linked to EXTI block but EXTI handles
>>> external interrupts only on edge. To be able to handle GPIO interrupt on
>>> level a "hack" is done in gpio irq chip: parent interrupt (exti irq
>>> chip)
>>> is retriggered following interrupt type and gpio line value.
>>>
>>> Signed-off-by: Alexandre Torgue <alexandre.torgue@...com>
>>> Tested-by: Marek Vasut <marex@...x.de>
>>
>> Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
>>
>> If Marc want to merge it with patch 1/2 go ahead!
> 
> I'll queue the whole thing for 5.7.

I have a feeling this doesn't work with threaded interrupts.

If the interrupt handler runs in a thread context, the EOI will happen
almost right away (while the IRQ handler runs) and so will the code
handling the IRQ retriggering. But since the IRQ handler still runs and
didn't return yet, the retriggering doesn't cause the IRQ handler to be
called again once it finishes, even if the IRQ line is still asserted.
And that could result in some of the retriggers now happening I think.
Or am I doing something wrong ?