IRQ_ONESHOT expectations vs mask/unmask

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

Hi Thomas !

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 ?

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

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

(For the newer P9 XIVE interrupt controller I can probably fix things
by using a different masking mechanism in HW but for the old XICS,
especially with the hypervisor under the hood, I'm less confident).

I'd rather not write my own flow handler, that's a recipe for missing
fixes going into the generic ones and horrible bitrot...

Cheers,
Ben.