netdev - Re: [PATCH net 2/2] net: phylink: Force retrigger in case of latched link-fail indicator

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:   Tue, 23 Nov 2021 11:40:50 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Marek Behún <kabel@...nel.org>
Cc:     netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
        Andrew Lunn <andrew@...n.ch>, davem@...emloft.net
Subject: Re: [PATCH net 2/2] net: phylink: Force retrigger in case of latched
 link-fail indicator

On Tue, Nov 23, 2021 at 12:51:54AM +0100, Marek Behún wrote:
> On mv88e6xxx 1G/2.5G PCS, the SerDes register 4.2001.2 has the following
> description:
>   This register bit indicates when link was lost since the last
>   read. For the current link status, read this register
>   back-to-back.
> 
> Thus to get current link state, we need to read the register twice.
> 
> But doing that in the link change interrupt handler would lead to
> potentially ignoring link down events, which we really want to avoid.
> 
> Thus this needs to be solved in phylink's resolve, by retriggering
> another resolve in the event when PCS reports link down and previous
> link was up.
> 
> The wrong value is read when phylink requests change from sgmii to
> 2500base-x mode, and link won't come up. This fixes the bug.

I've also been re-thinking this patch - I don't think it's sufficient
to completely solve the problem, and I think this is required to make
it bullet-proof.

I suspect the reason no problem is being seen is that normally, the
BMSR is read prior to calling phylink_mac_change() which will "unlatch"
the bit.

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 73cb97285caa..47fe16b4e387 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -1097,10 +1097,17 @@ static void phylink_resolve(struct work_struct *w)
 			phylink_mac_pcs_get_state(pl, &link_state);
 
 			/* The PCS may have a latching link-fail indicator.
-			 * If the PCS link goes down, retrigger a resolve.
+			 * If the link was up, bring the link down and
+			 * re-trigger the resolve. Otherwise, re-read the
+			 * PCS state to get the current status of the link.
 			 */
-			if (!link_state.link && cur_link_state)
-				retrigger = true;
+			if (!link_state.link) {
+				if (cur_link_state)
+					retrigger = true;
+				else
+					phylink_mac_pcs_get_state(pl,
+								  &link_state);
+			}
 
 			/* If we have a phy, the "up" state is the union of
 			 * both the PHY and the MAC

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