netdev - Re: [RFC net-next] net: dsa: generate port ifname if exists or invalid

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: <Zm2mOZGPuPstMdlB@makrotopia.org>
Date: Sat, 15 Jun 2024 15:33:30 +0100
From: Daniel Golle <daniel@...rotopia.org>
To: Vladimir Oltean <olteanv@...il.com>
Cc: John Thomson <git@...nthomson.fastmail.com.au>, andrew@...n.ch,
	f.fainelli@...il.com, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, robh@...nel.org,
	krzk+dt@...nel.org, conor+dt@...nel.org, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC net-next] net: dsa: generate port ifname if exists or
 invalid

Hi Vladimir,

On Thu, Jun 13, 2024 at 02:43:14PM +0300, Vladimir Oltean wrote:
> On Sat, Jun 08, 2024 at 11:47:24AM +1000, John Thomson wrote:
> > RFC:
> > Not a full solution.
> > 
> > Not sure if supported, I cannot see any users in tree DTS,
> > but I guess I would need to skip these checks (and should mark as
> > NEM_NAME_ENUM) if port->name contains '%'.
> > 
> > name is also used in alloc_netdev_mqs, and I have not worked out if any
> > of the functionality between alloc_netdev_mqs and the register_netdevice
> > uses name, so I added these test early, but believe without a rntl lock,
> > a colliding name could still be allocated to another device between this
> > introduced test, and where this device does lock and register_netdevice
> > near the end of this function.
> > To deal with this looks to require moving the rntl_lock before
> > these tests, which would lock around significantly more.
> > 
> > As an alternative, could we possibly always register an enumerated name,
> > then (if name valid) dev_change_name (not exported), while still within
> > the lock after register_netdevice?
> > 
> > Or could we introduce a parameter or switch-level DTS property that forces
> > DSA to ignore port labels, so that all network devices names can be
> > managed from userspace (using the existing port DSA label as intended name,
> > as this still seems the best place to define device labels, even if the
> > driver does not use this label)?
> 
> Why not just _not_ use the 'label' device tree property, and bring
> a decent udev implementation into OpenWrt which can handle persistent
> naming according to the labels on the box? Even within DSA, it is
> considered better practice to use udev rather than 'label'. Not to
> mention that once available, udev is a uniform solution for all network
> interfaces, unlike 'label'.

Sounds fine generally. Where would you store the device-specific renaming
rules while making sure you don't need to carry the rules for all devices
onto every single device? Would you generate a device-specific rootfs for
each and every device? For obvious reasons this is something we'd very
much like to avoid, as building individual filesystems for ~ 1000 devices
would be insane compared to having a bunch (< 100) of generic filesystems
which some of them fitting a large group (ie. same SoC) of boards.
Most OpenWrt devices out there are based on the same SoCs, so currently
the devices in the popular targets like MT7621 or IPQ40xx all share the
same target-wide kernel **and rootfs**.

tl;dr: The good thing about the 'label' property is certainly that such
board- specific details are kept in DT, and hence a generic rootfs can
deal with it.

As having the 'label' property applied also for non-DSA netdevs by the
kernel has been rejected we did come up with a simple userland
implementation:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=2a25c6ace8d833cf491a66846a0b9e7c5387b8f0

For interfaces added at a later stage at boot, ie. by loading kernel modules
or actual hotplug, we could do the same in a hotplug script.

So yes, dropping support for dealing with the 'label' property in kernel
entirely would also fix it for us, because then we would just always deal
with it in userland (still using the same property in DT, just not applied
by the kernel).

> 
> Full disclosure: I myself tried for about 30 minutes to convert the udev
> rules below into an /etc/hotplug.d script that procd would run, before
> getting the impression it's never going to work as intended, because by
> the time all relevant "add" actions run (built-in drivers), user space
> hasn't even loaded, and thus hasn't got a chance to run any hooks.
> I haven't actually opened the source code to compare how other uevent
> handlers deal with this.
> 
> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p0", NAME="swp0"
> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p1", NAME="swp1"
> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p2", NAME="swp2"
> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p3", NAME="swp3"
> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p4", NAME="swp4"
> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p5", NAME="swp5"
> 

Yes, this is a problem in general. We will need better coldplug support,
right now only devices added after procd is launched are taken care of.


Cheers


Daniel