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:   Wed, 17 Feb 2021 22:41:33 +0000
From:   "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>
To:     Finn Thain <fthain@...egraphics.com.au>
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



> -----Original Message-----
> From: Finn Thain [mailto:fthain@...egraphics.com.au]
> Sent: Sunday, February 14, 2021 6:11 PM
> To: Song Bao Hua (Barry Song) <song.bao.hua@...ilicon.com>
> Cc: Arnd Bergmann <arnd@...nel.org>; tglx@...utronix.de;
> gregkh@...uxfoundation.org; arnd@...db.de; geert@...ux-m68k.org;
> funaho@...ai.org; philb@....org; corbet@....net; mingo@...hat.com;
> linux-m68k@...ts.linux-m68k.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.

Basically, we wrote drivers with the assumption that this driver will
be cross-platform. (Of course there are some drivers which can only work
on one platform, for example, if the IP of the device is only used in
one platform as an internal component of a specific SoC.)

So once a device has two or more interrupts, we need to consider one
interrupt might preempt another one on m68k on the same cpu if we also
want to support this driver on m68k. this usually doesn't matter on
other platforms.

on the other hand, there are more than 400 irqs_disabled() in kernel,
I am really not sure if they are running with the knowledge that
the true irqs_disabled() actually means some interrupts are off
and some others are still open on m68k. Or they are running with
the assumption that the true irqs_disabled() means IRQ is totally
quiet? If the latter is true, those drivers might fail to work on
m68k as well.

Thanks
Barry