netdev - RE: [PATCH net] Revert "ixgbe: Manual AN-37 for troublesome link partners for X550 SFI"

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:
 <AM0PR04MB5490DFFC58A60FA38A994C5AEAEA2@AM0PR04MB5490.eurprd04.prod.outlook.com>
Date: Tue, 21 May 2024 16:49:24 +0000
From: Jeff Daly <jeffd@...icom-usa.com>
To: Simon Horman <horms@...nel.org>, Jacob Keller <jacob.e.keller@...el.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"kernel.org-fo5k2w@...arbi.fr" <kernel.org-fo5k2w@...arbi.fr>
Subject: RE: [PATCH net] Revert "ixgbe: Manual AN-37 for troublesome link
 partners for X550 SFI"



> -----Original Message-----
> From: Simon Horman <horms@...nel.org>
> Sent: Tuesday, May 21, 2024 12:42 PM
> To: Jacob Keller <jacob.e.keller@...el.com>
> Cc: netdev@...r.kernel.org; Jeff Daly <jeffd@...icom-usa.com>; kernel.org-
> fo5k2w@...arbi.fr
> Subject: Re: [PATCH net] Revert "ixgbe: Manual AN-37 for troublesome link
> partners for X550 SFI"
> 
> Caution: This is an external email. Please take care when clicking links or
> opening attachments.
> 
> 
> On Mon, May 20, 2024 at 05:21:27PM -0700, Jacob Keller wrote:
> > This reverts commit 565736048bd5f9888990569993c6b6bfdf6dcb6d.
> >
> > According to the commit, it implements a manual AN-37 for some
> > "troublesome" Juniper MX5 switches. This appears to be a workaround
> > for a particular switch.
> >
> > It has been reported that this causes a severe breakage for other
> > switches, including a Cisco 3560CX-12PD-S.
> >
> > The code appears to be a workaround for a specific switch which fails
> > to link in SFI mode. It expects to see AN-37 auto negotiation in order
> > to link. The Cisco switch is not expecting AN-37 auto negotiation.
> > When the device starts the manual AN-37, the Cisco switch decides that
> > the port is confused and stops attempting to link with it. This
> > persists until a power cycle. A simple driver unload and reload does
> > not resolve the issue, even if loading with a version of the driver which lacks
> this workaround.
> >
> > The authors of the workaround commit have not responded with
> > clarifications, and the result of the workaround is complete failure
> > to connect with other switches.
> >
> > This appears to be a case where the driver can either "correctly" link
> > with the Juniper MX5 switch, at the cost of bricking the link with the
> > Cisco switch, or it can behave properly for the Cisco switch, but fail
> > to link with the Junipir MX5 switch. I do not know enough about the
> > standards involved to clearly determine whether either switch is at
> > fault or behaving incorrectly. Nor do I know whether there exists some
> > alternative fix which corrects behavior with both switches.
> >
> > Revert the workaround for the Juniper switch.
> >
> > Fixes: 565736048bd5 ("ixgbe: Manual AN-37 for troublesome link
> > partners for X550 SFI")
> > Link:
> > https://lore.kernel.org/netdev/cbe874db-9ac9-42b8-afa0-88ea910e1e99@in
> > tel.com/T/
> > Link:
> > https://forum.proxmox.com/threads/intel-x553-sfp-ixgbe-no-go-on-pve8.1
> > 35129/#post-612291
> > Signed-off-by: Jacob Keller <jacob.e.keller@...el.com>
> > Cc: Jeff Daly <jeffd@...icom-usa.com>
> > Cc: kernel.org-fo5k2w@...arbi.fr
> 
> One of those awkward situations where the only known (in this case to Jacob
> and me) resolution to a regression is itself a regression (for a different setup).
> 
> I think that in these kind of situations it's best to go back to how things were.
> 
> Reviewed-by: Simon Horman <horms@...nel.org>

In principle, I don't disagree.....  However, our customer was very sensitive to having any patches/workarounds needed for their configuration be part of the upstream.  Aside from maintaining our own patchset (or figuring out whether there's a patch that works for everyone) is there a better solution?