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, 19 Oct 2015 07:50:40 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Sekhar Nori <nsekhar@...com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>,
	Marc Zyngier <marc.zyngier@....com>,
	John Ogness <john.ogness@...utronix.de>,
	Felipe Balbi <balbi@...com>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] irqchip: omap-intc: fix spurious irq handling

Hi,

* Sekhar Nori <nsekhar@...com> [151019 02:51]:
> Under some conditions, irq sorting procedure used by INTC can go wrong
> resulting in a spurious irq getting reported.
> 
> This condition is flagged by INTC by setting "Spurious IRQ Flag" in SIR
> register to 0x1ffffff. Section 6.2.5 of AM335x TRM revised Jun 2014
> describes this.

OK so we have this finally documented, that's great. It's been bugging
me for years now :) What we used to have for omap3 was 6ccc4c0dedf8
("ARM: OMAP3: Warn about spurious interrupts"). I alsways thought it's
some undocumented omap3 weirdness but obviously not if you're seeing it
on am335x too.

> Using IRQ number 0 for checking this condition is wrong. 0 is a valid
> INTC IRQ. For example, on AM335x, it is the emulation interrupt.
> 
> Fix handing of spurious interrupt condition in omap-intc driver by
> correct detection of spurious interrupt condition.
> 
> Since spurious IRQ condition can happen under genuine conditions (see
> the section of AM335x TRM for details) and is recoverable, we do not
> need a warning splat for users to report. It can however result in
> reduced performance so we add a ratelimited debug print to aid
> developers.

Do you know what really is causing the spurious interrupts in your
case?

In all the cases I've seen, the spurious interrupts were caused by
a missing flush of posted write acking the IRQ at the device driver.
for the _previously triggered_ INTC interrupt.

If you have a reproducable case, I suggest you test that by printing
out the previous interrupt to check if that makes sense. And then see
if adding the missing read back to that interrupt handler fixes the
issue.

And if my assumption is correct, you can then update your patch and
actually warn about the real culprit irq number :)

Regards,

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

Powered by blists - more mailing lists