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 08:29:33 +0200
From:   Andreas Tobler <andreas.tobler@...udguard.ch>
To:     Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Sven Müller <musv@....de>
Cc:     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

Hi all,

On 20.10.17 09:09, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 20 Oct 2017 00:25:24 +0200, Sven Müller wrote:
> 
>> First of all I'm not familiar with kernel programming at all, so
>> please excuse me, if I don't understand everything at the first
>> glance.
> 
> No problem. Your bug report and effort to nail down the issue are much
> appreciated!
> 
>> It compiles and runs fine. After a couple of hours and testing no
>> issues were found.
> 
> OK, so this really hints at a regression in the mvneta driver itself.
> 
> Could you try to revert just:
> 
>    6ad20165d376fa07919a70e4f43dfae564601829
>    a29b6235560a1ed10c8e1a73bfc616a66b802b90
>    2a90f7e1d5d04e4f1060268e0b55a2c702bbd67a
> 
> first all of them, and then each one by one, so that we can pin-point
> the commit that causes the breakage ?
> 
> I looked at all the other changes in mvneta between 4.10 and 4.12, and
> I don't see how any of the other changes can cause a functional
> difference. So let's focus on those 3 commits for the moment.

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