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]

Date:   Tue, 08 Jun 2021 23:32:25 +0300
From:   Nikolai Zhubr <zhubr.2@...il.com>
To:     Arnd Bergmann <arnd@...nel.org>
CC:     netdev <netdev@...r.kernel.org>
Subject: Re: Realtek 8139 problem on 486.

08.06.2021 10:44, Arnd Bergmann:
[...]
> 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

For this to work, napi_complete should likely be called with some 
different condition instead?
E.g.:

-        if (work_done < budget) {
+        if ((work_done < budget) && !status) {

Otherwise polling would possibly be shut down before all non-rx events 
are cleared?
For some reason such 'corrected' version does not work here though 
(Communication fails completely). Probably I'm still missing something.

Thank you,

Regards,
Nikolai

> 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
>