netdev - Re: Realtek 8139 problem on 486.

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: <CAK8P3a30Pz+_Mud-VYsMw9XEsE5KBUHyMF4KzUr9XYiXi9D91g@mail.gmail.com>
Date:   Mon, 21 Jun 2021 17:20:59 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Nikolai Zhubr <zhubr.2@...il.com>,
        netdev <netdev@...r.kernel.org>, Jeff Garzik <jgarzik@...ox.com>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: Realtek 8139 problem on 486.

On Mon, Jun 21, 2021 at 4:42 PM Maciej W. Rozycki <macro@...am.me.uk> wrote:
>
> On Mon, 21 Jun 2021, Arnd Bergmann wrote:
>
> > I also found an slightly more recent discussion, from where it seems
> > that the authoritative decision when it came up in the past was that edge
> > triggered interrupts are supposed to work as long as they are not
> > shared [3][4].
>
>  Sadly Linus's rule applies both ways: if a device has been designed with
> level-triggered interrupts in mind, there may be no race-free way to
> ensure an active-to-inactive-to-active transition has happened on its IRQ
> line as the driver acknowledges handling in the relevant device's CSR.
>
>  The rule of thumb is to acknowledge early in the handler, and to work
> around broken configurations it may be desirable to also briefly mask all
> the interrupt sources with the device so as to make sure it deasserts its
> IRQ line even if another interrupt has already been queued.  OTOH if IRQ
> sharing is to be supported a device absolutely has to have an interrupt
> mask register, as the system cannot rely on masking at the interrupt
> controller if multiple devices are to be handled with a single line.  I
> suspect many of our drivers do not do such precautionary masking though.
>
>  Is there a mask register with the 8139?

Ah, it seems that the Cc list got dropped in a different sub-thread, see
https://pastebin.com/3FUUrg7C for a version of my patch that Nikolai
tested successfully. This one goes further by completely masking
all interrupts between the hardirq handler and the subsequent
napi_complete_done(). This may not be the most efficient way of
doing it, but it seems good enough according to his measurements,
and it is a relatively safe and straightforward change.

      Arnd