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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191002121916.GB20028@lunn.ch>
Date:   Wed, 2 Oct 2019 14:19:16 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Denis Odintsov <d.odintsov@...viangames.com>
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

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