netdev - Re: Problems with mvneta

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, 23 Oct 2017 11:30:24 +0200
From:   Sven Müller <musv@....de>
To:     Andreas Tobler <andreas.tobler@...udguard.ch>
Cc:     Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Grégory Clement 
        <gregory.clement@...e-electrons.com>,
        Antoine Ténart 
        <antoine.tenart@...e-electrons.com>, netdev@...r.kernel.org,
        Marcin Wojtas <mw@...ihalf.com>
Subject: Re: Problems with mvneta

I've tested a lot on weekend, but the results are still contradictory and therefore not reliable enough.

Kernel 4.13.7 with driver of that version: 

Reverted all 3 patches: 6ad2, a29b, 2a90: works fine. No issues.
Applied only 6ad2: Got the nfs socket shutdown error on the first test, but yesterday it has been worked perfectly for a lot of hours. 
Applied only a29b: No issues
Applied only 2a90: No issues. 
Applied a29b and 2a90: No issues. 

The main problem is to create a reproducible crash scenario. 

Regards
Sven

Am Mon, 23 Oct 2017 08:29:33 +0200
schrieb Andreas Tobler <andreas.tobler@...udguard.ch>:

> Hi all,
> 
> 
> We did also experience some issues with the mvneta driver.
> 
> I nailed it down to the BQL commit. 
> (a29b6235560a1ed10c8e1a73bfc616a66b802b90 net: mvneta: add BQL
> support)
> 
> Here we did an upgrade from 4.10.13 to 4.13.5. Before it was stable
> and a 4.13.5 with the 4.10.13 driver was also ok.
> 
> Our scenario is the following, the board we use acts as router and 
> forwards some traffic. To distribute the load to both cpu's we have,
> we enabled RPS (receive packet steering). Now as soon as we stress
> the router with iperf3 the eth links go down. The router sits between
> a client and a server where we blow load with iperf3.
> 
> If we disable RPS, the links seems stable.
> 
> Doing the iperf3 tests from/to the router directly, iperf3 client is 
> started on the router, does not show any instability.
> 
> Maybe these observations help to find out what's going on.
> 
> Thx,
> Andreas