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]

Message-ID: <CAMuHMdVD+BhxXcmZYvVK5QgtNsmbgyzS_Yx+dbFYmN8xdw0kDA@mail.gmail.com>
Date:   Thu, 18 Feb 2021 16:38:40 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Arnd Bergmann <arnd@...nel.org>
Cc:     Finn Thain <fthain@...egraphics.com.au>,
        "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "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

Hi Arnd,

On Thu, Feb 18, 2021 at 2:59 PM Arnd Bergmann <arnd@...nel.org> wrote:
> On Thu, Feb 18, 2021 at 1:30 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > The reason drivers/ide is doing that may be related to IDE hard drive
> > quirks.  The old WD Caviar drives didn't obey disabling the IDE interrupt
> > at the drive level.  On PC, that worked fine, as IRQs 14 and 15 weren't
> > shared with other devices.  On systems with shared interrupts, that
> > broke badly, and led to an interrupt storm.
>
> So presumably anyone that has one of those old drives will not be
> able to move to drivers/ata then? I see that drivers/ata doesn't do
> the transfers in interrupt mode, so it would seem to rely on masking
> at the device level.

I don't know.  This was an issue I debugged on a friend's Amiga in 1995
or so ;-)  All bad WD Caviars may have died in the meantime...

BTW, it wouldn't be the first time a drive quirk handling wasn't ported
from drivers/ide/ to drivers/ata/.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds