RE: [tip:irq/core] genirq: Fix race on spurious interrupt detection

[Thomas Gleixner]

David,

On Fri, 19 Oct 2018, Thomas Gleixner wrote:
> On Fri, 19 Oct 2018, David Laight wrote:
> > From: Lukas Wunner
> > > Sent: 19 October 2018 16:34
> > > 
> > > genirq: Fix race on spurious interrupt detection
> > > 
> > > Commit 1e77d0a1ed74 ("genirq: Sanitize spurious interrupt detection of
> > > threaded irqs") made detection of spurious interrupts work for threaded
> > > handlers by:
> > > 
> > > a) incrementing a counter every time the thread returns IRQ_HANDLED, and
> > > b) checking whether that counter has increased every time the thread is
> > >    woken.
> > 
> > That seems horribly broken.
> > What is it trying to achieve?
> > 
> > There are (at least) two common cases where IRQ_HANDLED doesn't get returned.
> > (Unless the driver always returns it to avoid the message.)
> > 
> > 1) The IOW that causes the hardware to drop a level sensitive IRQ is posted
> >    on the bus (etc) and happens late enough that the IRQ line is still
> >    asserted when the iret executes.
> >    If this happens all the time you need to flush the IOW, but if only
> >    occasionally it doesn't matter and you don't want a message.
> >
> > 2) Typically an ethernet driver ISR has to enable the interrupt and then
> >    check the ring for work before returning from the interrupt.
> >    If a packet arrives at this time it might be processed by the 'old'
> >    ISR invocation but still generate another interrupt.
> >    If no more packets arrive the second ISR invocation will find no work.
> >    Again this is normal behaviour.
> >    (Deferring everything with NAPI might make this not happen - but other
> >    interrupts end up working the same way.)
> > 
> > If you are really trying to detect 'stuck' interrupts then you probably
> > want to count un-handled ones and zero the count on handled ones.
> > I'm also pretty sure you don't need an atomic counter.
> 
> Care to look at the logic which handles all of this including the
> interaction with threaded interrupt handlers?

Sorry for being dense. Wanted to postpone and hit send ...

The thing is that the spurious detector works perfectly fine for the
scenarios you described since years. It does proper handled vs. unhandled
accounting.

What Lukas is addressing is not the normal interrupt case, it's the
threaded handler case where we did the accounting check after reenabling
the interrupt, which causes spurious detection to trigger
occasionally. That's not leading to disabling the interrupt unless you
enforce it with a gazillion of printks.

The atomic counter is necessary in that case because for certain scenarios
the hard interrupt handler can race with the threaded handler legitimately.

Thanks,

	tglx