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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a12-c136eHmjiN+BJfZYfRjXz6hk25uo_DMf+tvbTDzGw@mail.gmail.com>
Date:   Tue, 8 Jun 2021 09:44:00 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     Nikolai Zhubr <zhubr.2@...il.com>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        netdev <netdev@...r.kernel.org>
Subject: Re: Realtek 8139 problem on 486.

On Tue, Jun 8, 2021 at 1:07 AM Nikolai Zhubr <zhubr.2@...il.com> wrote:
> 02.06.2021 12:12, Arnd Bergmann:
> [...]
> > I think the easiest workaround to address this reliably would be to move all
> > the irq processing into the poll function. This way the interrupt is completely
> > masked in the device until the poll handler finishes, and unmasking it
> > while there
> > are pending events would reliably trigger a new irq regardless of level or edge
> > mode. Something like the untested change at https://pastebin.com/MhBJDt6Z .
> > I don't know of other drivers that do it like this though, so I'm not
> > sure if this causes a different set of problems.
>
> I started applying your patch (trying to morph it a little bit so as to
> shove in a minimally invasive manner into 4.14) and then noticed that it
> probably won't work as intended. If I'm not mistaken this rx poll thing
> is only active within kind of "rx bursts", so it is not guaranteed to be
> continually running all the time when there is no or little rx input.
> I'd suppose some new additional work/thread would have to be introduced
> in order for such approach to be reliably implemented.

The basic idea of the napi poll function is to do batch processing as much
as possible and avoid excessive interrupts when the system is already
busy processing the received data.

However, it should not lead to any missed interrupts with my patch:
at any point in time, you have either all hardware interrupts enabled,
or you are in napi polling mode and are guaranteed to call the poll
function within a relatively short timespan. If you have no pending
rx events, processing should be pretty much instantaneous, it just
gets pushed from the irq handler to immediately following the irq
handler. If there is a constant stream of incoming data, it gets
moved into softirqd context, which may be delayed when there is
another thread running.

        Arnd