netdev - Re: status of rate adaptation

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]

Date:   Sat, 12 Nov 2022 13:15:46 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Sean Anderson <sean.anderson@...o.com>
Cc:     Tim Harvey <tharvey@...eworks.com>,
        netdev <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: status of rate adaptation

On Fri, Nov 11, 2022 at 04:54:40PM -0500, Sean Anderson wrote:
> > [    8.911932] mvpp2 f2000000.ethernet eth0: PHY
> > [f212a600.mdio-mii:08] driver [Aquantia AQR113C] (irq=POLL)
> > [    8.921577] mvpp2 f2000000.ethernet eth0: phy: 10gbase-r setting
> > supported 00000000,00018000,000e706f advertising
> > 00000000,00018000,000e706f

> > # ethtool eth0
> > Settings for eth0:
> >         Supported ports: [ ]
> >         Supported link modes:   10baseT/Half 10baseT/Full
> >                                 100baseT/Half 100baseT/Full
> 
> 10/100 half duplex aren't achievable with rate matching (and we avoid
> turning them on), so they must be coming from somewhere else. I wonder
> if this is because PHY_INTERFACE_MODE_SGMII is set in
> supported_interfaces.

The reason is due to the way phylink_bringup_phy() works. This is
being called with interface = 10GBASE-R, and the PHY is a C45 PHY,
which means we call phy_get_rate_matching() with 
PHY_INTERFACE_MODE_NA as we don't know whether the PHY will be
switching its interface or not.

Looking at the Aquanta PHY driver, this will return that pause mode
rate matching will be used, so config.rate_matching will be
RATE_MATCH_PAUSE.

phylink_validate() will be called for PHY_INTERFACE_MODE_NA, which
causes it to scan all supported interface modes (as again, we don't
know which will be used by the PHY [*]) and the union of those
results will be used.

So when we e.g. try SGMII mode, caps & mac_capabilities will allow
the half duplex modes through.

Now for the bit marked with [*] - at this point, if rate matching is
will be used, we in fact know which interface mode is going to be in
operation, and it isn't going to change. So maybe we need this instead
in phylink_bringup_phy():

-	if (phy->is_c45 &&
+	config.rate_matching = phy_get_rate_matching(phy, interface);
+	if (phy->is_c45 && config.rate_matching == RATE_MATCH_NONE &&
            interface != PHY_INTERFACE_MODE_RXAUI &&
            interface != PHY_INTERFACE_MODE_XAUI &&
            interface != PHY_INTERFACE_MODE_USXGMII)
                config.interface = PHY_INTERFACE_MODE_NA;
        else
                config.interface = interface;
-	config.rate_matching = phy_get_rate_matching(phy, config.interface);

        ret = phylink_validate(pl, supported, &config);

?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!