netdev - Re: About r8169 regression 5.4

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:   Mon, 24 Feb 2020 20:49:42 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Vincas Dargis <vindrg@...il.com>,
        Salvatore Bonaccorso <carnil@...ian.org>
Cc:     netdev@...r.kernel.org
Subject: Re: About r8169 regression 5.4

On 21.02.2020 21:21, Vincas Dargis wrote:
> 2020-02-20 20:32, Heiner Kallweit rašė:
>> It would be great if you could test one more thing. Few chip versions have a hw issue with tx checksumming
>> for very small packets. Maybe your chip version suffers from the same issue.
>> Could you please test the following patch (with all features enabled, TSO and checksumming)?
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index 8442b8767..bee90af57 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -4345,6 +4345,7 @@ static netdev_features_t rtl8169_features_check(struct sk_buff *skb,
>>               case RTL_GIGA_MAC_VER_12:
>>               case RTL_GIGA_MAC_VER_17:
>>               case RTL_GIGA_MAC_VER_34:
>> +            case RTL_GIGA_MAC_VER_44:
>>                   features &= ~NETIF_F_CSUM_MASK;
>>                   break;
>>               default:
>>
> 
> Sadly, network got hanged after ~1.5h of usage. I've built it with Debian's "debian/bin/test-patches" helper (kernel is now named 5.4.19-1a~test),
> double-checked that line was actually added in source. `ethtool -K enp5s0f1 tx on sg on tso on` was executed after boot.

Realtek responded that they can't reproduce the issue. They suggested to not enable tx offloading
per default as a workaround. So for now you have to disable tx offloading via ethtool.