linux-kernel - Re: ethtool settings and SFP modules with PHYs

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: <Zum5VTDZSv3d46aD@makrotopia.org>
Date: Tue, 17 Sep 2024 18:16:05 +0100
From: Daniel Golle <daniel@...rotopia.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Maxime Chevallier <maxime.chevallier@...tlin.com>,
	Andrew Lunn <andrew@...n.ch>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, Heiner Kallweit <hkallweit1@...il.com>,
	Kory Maincent <kory.maincent@...tlin.com>,
	Edward Cree <ecree.xilinx@...il.com>,
	Paolo Abeni <pabeni@...hat.com>, Jakub Kicinski <kuba@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	"David S. Miller" <davem@...emloft.net>,
	John Crispin <john@...ozen.org>
Subject: Re: ethtool settings and SFP modules with PHYs

On Tue, Sep 17, 2024 at 05:38:39PM +0100, Russell King (Oracle) wrote:
> On Tue, Sep 17, 2024 at 05:53:47PM +0200, Maxime Chevallier wrote:
> > For the SFP case, the notification would trigger indeed at the
> > module_start/module_remove step.
> 
> This (the confusion of module_remove being the opposite of
> module_start)...
> 
> > 
> > All of that is still WIP, but I think it would reply to that exact need
> > of "notifying users when something happens to the ports", including SFP
> > module insertion.
> 
> and talking here about module insertion here, leads me to believe that
> you haven't grasped the problem with SFPs, where we don't know what
> the module supports at _insertion_ time.
> 
> If we're after giving userspace a notification so it can make decisions
> about what to do after examining capabilities, then insertion time is
> too early.
> 

Exactly. It needs to be after the PHY has been probed (which can take
up to 25 seconds after insertion).

> If we're after giving userspace a notification e.g. that a SFP was
> inserted, so please bring up the network interface, then that may be
> useful, but userspace needs to understand that SFPs are special and
> they can't go configuring the link at this point if it's a SFP.
> 
> Honestly, I do not want to expose to userspace this kind of complexity
> that's specific to SFPs. It _will_ get it wrong. I also think that it
> will tie our hands when working around module problems if we have to
> change the way module capabilities are handled - and I don't wish to
> be tied by "but that change you made to make module XYZ work breaks
> my userspace!" because someone's using these events to do some weirdo
> configuration.

The problem I'm trying to address (see initial post) is that the user may
want to configure some properties of the link, such as whether or not to
announce flow-control capabilities to the link partner, or (more rarely)
to limit to think speed to, let's say 100M/Full, even though 1000M/Full
would be possible, e.g. to work around problems with bad cabling.

Doing so, even right now, doesn't require much specific knowledge about
the MAC or SFP/PHY capabilities, all we need to do is to clear some
bits from the advertised field. So in my case userspace doesn't make
any attempt to identify the MAC ro SFP/PHY capabilities or act according
to them.

Currently, in order to know *when* to apply those settings (again) I'm
relying on an unreliable hack upon receiving RTNL events:

if ((flags & IFF_UP) && !(flags & IFF_LOWER_UP))
	system_set_ethtool_settings(dev, &dev->settings);

And that doesn't work well, which is why I started to reach out if there
is a better solution for that.