netdev - Re: [PATCH net 1/2] s390/qeth: update cached link

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