linux-kernel - Re: IRQ_ONESHOT expectations vs mask/unmask

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]

Date:   Mon, 31 Jul 2017 09:09:22 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Benjamin Herrenschmidt <benh@...nel.crashing.org>
cc:     Daniel Lezcano <daniel.lezcano@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: IRQ_ONESHOT expectations vs mask/unmask

Ben,

On Mon, 31 Jul 2017, Benjamin Herrenschmidt wrote:
> I noticed a problem with some powerpc systems with threaded IRQs. I
> hadn't looked at threaded irq in the past so there was a bit of
> discovery involved. That lead to a few questions:
> 
>  - Threaded IRQs rely on IRQF_ONESHOT. Now, is that a flag/feature that
> is generally exposed to drivers even in the non-threaded case, and if
> yes, what core callback are drivers expected to use to "unmask" the
> oneshot interrupt ?

The oneshot flag should not have any effects when the interrupt is
non-threaded. Emphasis on should. I'm not sure whether that's true, will
have a look.

>  - I don't see any provisions for dealing with interrupts lost while
> masked. So on some PICs on powerpc, while we do use "fast EOI", we also
> have a chance of edge interrupts (MSIs) being lost while masked. This
> wasn't a problem until now because we used lazy disabling. However, it
> looks like IRQF_ONESHOT (and thus threaded irqs) rely on masked
> interrupts being latched in HW, otherwise an interrupt might be lost
> between the threaded handler completing and the interrupt being
> unmasked, or am I missing something ?
>
>  - I noticed that other flow handlers (edge, edge_eoi, ...) don't have
> any provision for IRQF_ONESHOT. Isn't that a problem ? Or will the core
> silently swallow subsequent interrupts until the thread has completed
> anyway ? (I might be missing something here).

The only case where IRQF_ONESHOT should have an effect is with level type
interrupts. That's required, because otherwise the hardware interrupt would
fire for ever. Level type interrupts should not need any hardware latching,
we assume that they fire once they are unmasked.

For edge type interrupts we do not mask the interrupt in order not to lose
an interrupt. If the interrupt fires while the thread handler is running,
we mark the thread and once it the handler returns it gets called again.

> Generally, how do you suggest I fix the threaded irq problem for XICS ?

You asked a lot of questions, but you failed to explain the problem for
XICS.

Thanks,

	tglx