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] [day] [month] [year] [list]
Message-ID: <20251128141710.4fa38296@kernel.org>
Date: Fri, 28 Nov 2025 14:17:10 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, Oleksij Rempel <o.rempel@...gutronix.de>,
 Vladimir Oltean <vladimir.oltean@....com>, Alexei Starovoitov
 <ast@...nel.org>, Eric Dumazet <edumazet@...gle.com>, Rob Herring
 <robh@...nel.org>, Florian Fainelli <f.fainelli@...il.com>, Donald Hunter
 <donald.hunter@...il.com>, Daniel Borkmann <daniel@...earbox.net>, Jonathan
 Corbet <corbet@....net>, John Fastabend <john.fastabend@...il.com>, Lukasz
 Majewski <lukma@...x.de>, Maxime Chevallier
 <maxime.chevallier@...tlin.com>, Stanislav Fomichev <sdf@...ichev.me>,
 Paolo Abeni <pabeni@...hat.com>, Jiri Pirko <jiri@...nulli.us>, Jesper
 Dangaard Brouer <hawk@...nel.org>, Divya.Koppera@...rochip.com, Kory
 Maincent <kory.maincent@...tlin.com>, Vadim Fedorenko
 <vadim.fedorenko@...ux.dev>, netdev@...r.kernel.org, Sabrina Dubroca
 <sd@...asysnail.net>, linux-kernel@...r.kernel.org, kernel@...gutronix.de,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, "David S. Miller"
 <davem@...emloft.net>, Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH net-next v8 1/1] Documentation: net: add flow control
 guide and document ethtool API

On Fri, 28 Nov 2025 20:38:28 +0000 Russell King (Oracle) wrote:
> On Fri, Nov 28, 2025 at 09:16:24PM +0100, Andrew Lunn wrote:
> > > Can you please tell me what is preventing us from deprecating pauseparam
> > > API *for autoneg* and using linkmodes which are completely unambiguous.  
> > 
> > Just to make sure i understand you here...
> > 
> > You mean make use of
> > 
> >         ETHTOOL_LINK_MODE_Pause_BIT             = 13,
> >         ETHTOOL_LINK_MODE_Asym_Pause_BIT        = 14,
> > 
> > So i would do a ksettings_set() with
> > 
> > __ETHTOOL_LINK_MODE_LEGACY_MASK(Pause) | __ETHTOOL_LINK_MODE_LEGACY_MASK(Asym_Pause)
> > 
> > to indicate both pause and asym pause should be advertised.
> > 
> > The man page for ethtool does not indicate you can do this. It does
> > have a list of link mode bits you can pass via the advertise option to
> > ethtool -s, bit they are all actual link modes, not features like TP,
> > AUI, BNC, Pause, Backplane, FEC none, FEC baser, etc.  
> 
> I see the latest ethtool now supports -s ethX advertise MODE on|off,
> but it doesn't describe that in the parameter entry for "advertise"
> and doesn't suggest what MODE should be, nor how to specify multiple
> modes that one may wish to turn on/off. I'm guessing this is what you're
> referring to.
> 
> The ports never get advertised, so I don't think they're relevant.
> 
> However, the lack of the pause bits means that one is forced to use
> the hex number, and I don't deem that to be a user interface. That's
> a programmers interface, or rather a nightmare, because even if you're
> a programmer, you still end up looking at include/uapi/linux/ethtool.h
> and doing the maths to work out the hex number to pass, and then you
> mistype it with the wrong number of zeros, so you try again, and
> eventually you get the advertisement you wanted.
> 
> So no, I don't accept Jakub's argument right now. Forcing people into
> the nightmare of working out a hex number isn't something for users.

I did some digging, too, just now. Looks like the options are indeed
not documented in the man page but ethtool uses the "forward compatible"
scheme with strings coming from the kernel. So this:

  ethtool -s enp0s13f0u1u1 advertise Pause on Asym_Pause on

works just fine, with no changes in CLI.

We should probably document that it works in the ethtool help and man
page. And possibly add some synthetic options like Receive-Only /
Transmit-Only so that users don't have to be aware of the encoding
details? Let me know if it's impractical, otherwise I think we'll
agree that having ethtool that makes it obvious how to achieve the
desired configuration beats best long form docs in the kernel..

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ