linux-kernel - RE: [RFC] IRQ handlers run with some high-priority interrupts(not NMI) enabled on some platform

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:   Sun, 14 Feb 2021 16:10:30 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>
cc:     Arnd Bergmann <arnd@...nel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "geert@...ux-m68k.org" <geert@...ux-m68k.org>,
        "funaho@...ai.org" <funaho@...ai.org>,
        "philb@....org" <philb@....org>, "corbet@....net" <corbet@....net>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC] IRQ handlers run with some high-priority interrupts(not
 NMI) enabled on some platform

On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote:

> 
> So what is really confusing and a pain to me is that:
> For years people like me have been writing device drivers
> with the idea that irq handlers run with interrupts
> disabled after those commits in genirq. So I don't need
> to care about if some other IRQs on the same cpu will
> jump out to access the data the current IRQ handler
> is accessing.
> 
> but it turns out the assumption is not true on some platform.
> So should I start to program devices driver with the new idea
> interrupts can actually come while irqhandler is running?
> 
> That's the question which really bothers me.
> 

That scenario seems a little contrived to me (drivers for two or more 
devices sharing state through their interrupt handlers). Is it real? 
I suppose every platform has its quirks. The irq lock in sonic_interrupt() 
is only there because of a platform quirk (the same device can trigger 
either of two IRQs). Anyway, no-one expects all drivers to work on all 
platforms; I don't know why it bothers you so much when platforms differ.