netdev - Re: [BUG] mv88e6xxx: tx regression in v5.3

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]

Message-ID: <20191215161423.GE22725@lunn.ch>
Date:   Sun, 15 Dec 2019 17:14:23 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Baruch Siach <baruch@...s.co.il>
Cc:     Marek Behun <marek.behun@....cz>,
        Vivien Didelot <vivien.didelot@...il.com>,
        netdev@...r.kernel.org,
        Denis Odintsov <d.odintsov@...viangames.com>,
        Hubert Feurstein <h.feurstein@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [BUG] mv88e6xxx: tx regression in v5.3

On Sun, Dec 15, 2019 at 05:08:01PM +0200, Baruch Siach wrote:
> Hi Andrew,
> 
> On Sun, Dec 15 2019, Andrew Lunn wrote:
> >> This fixes cpu port configuration for me:
> >>
> >> diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
> >> index 7fe256c5739d..a6c320978bcf 100644
> >> --- a/drivers/net/dsa/mv88e6xxx/port.c
> >> +++ b/drivers/net/dsa/mv88e6xxx/port.c
> >> @@ -427,10 +427,6 @@ static int mv88e6xxx_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
> >>  		cmode = 0;
> >>  	}
> >>
> >> -	/* cmode doesn't change, nothing to do for us */
> >> -	if (cmode == chip->ports[port].cmode)
> >> -		return 0;
> >> -
> >>  	lane = mv88e6xxx_serdes_get_lane(chip, port);
> >>  	if (lane) {
> >>  		if (chip->ports[port].serdes_irq) {
> >>
> >> Does that make sense?
> >
> > This needs testing on a 6390, with a port 9 or 10 using fixed link. We
> > have had issues in the past where mac_config() has been called once
> > per second, and each time it reconfigured the MAC, causing the link to
> > go down/up. So we try to avoid doing work which is not requires and
> > which could upset the link.
> 
> You refer to ed8fe20205ac ("net: dsa: mv88e6xxx: prevent interrupt storm
> caused by mv88e6390x_port_set_cmode") that introduced this code.
> 
> The alternative is to call ->port_get_cmode() to refresh the cmode cache
> after mv88e6xxx_port_hidden_write().

Refreshing the cmode after mv88e6xxx_port_hidden_write() sounds like a
good idea. But please limit it to just switches which need to make
cmode writable. cmode is rather fragile and the 6390 family is easy to
break in this area.

      Thanks
		Andrew