linux-kernel - Re: [PATCH] genirq: Fix race on spurious interrupt detection

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]

Date:   Fri, 19 Oct 2018 17:26:29 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Lukas Wunner <lukas@...ner.de>
cc:     linux-kernel@...r.kernel.org,
        Mathias Duckeck <m.duckeck@...bus.de>,
        Akshay Bhat <akshay.bhat@...esys.com>,
        Casey Fitzpatrick <casey.fitzpatrick@...esys.com>
Subject: Re: [PATCH] genirq: Fix race on spurious interrupt detection

On Fri, 19 Oct 2018, Lukas Wunner wrote:
> On Fri, Oct 19, 2018 at 04:31:30PM +0200, Thomas Gleixner wrote:
> > I doubt that this can happen in reality, so I'd rather reword that
> > paragraph slightly:
> > 
> >   In theory high CPU load and in the presence of higher priority tasks, the
> >   number of incorrectly detected spurious interrupts might increase beyond
> >   the 99,900 threshold and cause disablement of the interrupt.
> > 
> >   In practice it just increments the spurious interrupt count. But that can
> >   cause people to waste time investigating it over and over.
> > 
> > Hmm?
> 
> Sure, fine by me.  Would you prefer me to resend with that change or
> can you fold it in when applying?

I'll fold it. No problem.

> FWIW I did manage to reach the 99,900 threshold once because I had
> added copious amounts of printk() to the hi3110 IRQ thread to debug
> another issue.  But I never experienced that without those printk()'s.

Cute.

Thanks

	tglx