netdev - Re: Marvell 88E6141 DSA degrades after 7fb5a711545d7d25fe9726a9ad277474dd83bd06

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: <73A3CAFD-56DB-4E09-8830-606B489C3754@traviangames.com>
Date:   Thu, 3 Oct 2019 08:52:34 +0000
From:   Denis Odintsov <d.odintsov@...viangames.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "vivien.didelot@...il.com" <vivien.didelot@...il.com>,
        "h.feurstein@...il.com" <h.feurstein@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Marvell 88E6141 DSA degrades after
 7fb5a711545d7d25fe9726a9ad277474dd83bd06

Hello,

Thank you for your reply, now that you've said that I actually put WARN_ON(1) into mv88e6xxx_adjust_link and found out that it is not actually being called. Not even on 5.3. What I saw was a warning produced by block like "if (ds->ops->adjust_link)" in net/dsa/ code, but not the actual call. My bad. So it seems the content of the function is irrelevant, and as I can see there are many block like this, so most probably it is something one of these blocks were doing on 5.3 which changed to 5.4, which is way harder to debug I guess. Any other things I could check in that matter?

Denis. 

> Am 02.10.2019 um 14:19 schrieb Andrew Lunn <andrew@...n.ch>:
> 
> On Wed, Oct 02, 2019 at 11:57:30AM +0000, Denis Odintsov wrote:
>> Hello,
>> 
>> Hope you are doing fine, I have a report regarding Marvell DSA after 7fb5a711545d7d25fe9726a9ad277474dd83bd06<https://github.com/torvalds/linux/commit/7fb5a711545d7d25fe9726a9ad277474dd83bd06> patch.
>> 
>> Thing is that after this commit:
>> https://github.com/torvalds/linux/commit/7fb5a711545d7d25fe9726a9ad277474dd83bd06
>> on linux 5.3 DSA stopped working properly for me.
>> I'm using Clearfog GT 8k board, with 88E6141 switch and bridge config where all lanN interfaces are bridged together and ip is assigned to the bridge.
>> 
>> It stopped working properly in the matter that everything fires up from the board point of view, interfaces are there, all is good, but there are never any packet registered as RX on lanN interfaces in counters. Packets are always TX'ed and 0 as RX. But! This is where weird starts, the actual link is negotiated fine (I have 100Mb clients, and interfaces have correct speed and duplex, meaning they actually handshake with the other end). Even more, if I would set ip lanN interface itself with ip address, the networks somehow work, meaning a client, if set ip manually, can kind of ping the router, but with huge volatile times, like >300ms round trip. And still not a single RX packet on the interface shown in the counter.
>> 
>> So this is really weird behaviour, and the most sad part in that is that while on 5.3 with this patch reverted everything start to work fine, the trick doesn't work for 5.4 anymore.
> 
> Hi Denis
> 
> Could you give us the call stack when mv88e6xxx_adjust_link() is used
> in 5.3. A WARN_ON(1) should do that.
> 
> We are probably missing a use case where it is used, but we did not
> expect it to be used. The call stack should help us find that use
> case.
> 
> Thanks
> 	Andrew