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:   Thu, 4 Aug 2022 15:08:11 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Alexandra Winter <wintera@...ux.ibm.com>
Cc:     David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-s390@...r.kernel.org, Heiko Carstens <hca@...ux.ibm.com>,
        Thorsten Winkler <twinkler@...ux.ibm.com>
Subject: Re: [PATCH net 1/2] s390/qeth: update cached link_info for ethtool

On Thu, Aug 04, 2022 at 10:53:33AM +0200, Alexandra Winter wrote:
> 
> 
> On 03.08.22 17:19, Andrew Lunn wrote:
> > On Wed, Aug 03, 2022 at 04:40:14PM +0200, Alexandra Winter wrote:
> >> Speed, duplex, port type and link mode can change, after the physical link
> >> goes down (STOPLAN) or the card goes offline
> > 
> > If the link is down, speed, and duplex are meaningless. They should be
> > set to DUPLEX_UNKNOWN, SPEED_UNKNOWN. There is no PORT_UNKNOWN, but
> > generally, it does not change on link up, so you could set this
> > depending on the hardware type.
> > 
> > 	Andrew
> 
> Thank you Andrew for the review. I fully understand your point.
> I would like to propose that I put that on my ToDo list and fix
> that in a follow-on patch to net-next.
> 
> The fields in the link_info control blocks are used today to generate
> other values (e.g. supported speed) which will not work with *_UNKNOWN,
> so the follow-on patch will be more than just 2 lines.

So it sounds like your code is all backwards around. If you know what
the hardware is, you know the supported link modes are, assuming its
not an SFP and the SFP module is not plugged in. Those link modes
should be independent of if the link is up or not. speed/duplex is
only valid when the link is up and negotiation has finished.

Since this is for net, than yes, maybe it would be best to go with a
minimal patch to make your backwards around code work. But for
net-next, you really should fix this properly. 

	  Andrew

Powered by blists - more mailing lists