linux-kernel - RE: [RFC PATCH] net: dsa: microchip: Prevent overriding of HSR port forwarding

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:
 <DM3PR11MB8736A15C582626DE95429F6EEC37A@DM3PR11MB8736.namprd11.prod.outlook.com>
Date: Sat, 16 Aug 2025 00:53:50 +0000
From: <Tristram.Ha@...rochip.com>
To: <frieder@...s.de>
CC: <netdev@...r.kernel.org>, <davem@...emloft.net>, <edumazet@...gle.com>,
	<kuba@...nel.org>, <linux-kernel@...r.kernel.org>, <lukma@...x.de>,
	<pabeni@...hat.com>, <UNGLinuxDriver@...rochip.com>, <olteanv@...il.com>,
	<Woojung.Huh@...rochip.com>, <andrew@...n.ch>, <frieder.schrempf@...tron.de>,
	<florian.fainelli@...adcom.com>, <jesseevg@...il.com>,
	<o.rempel@...gutronix.de>, <pieter.van.trappen@...n.ch>,
	<rmk+kernel@...linux.org.uk>, <horms@...nel.org>, <vadim.fedorenko@...ux.dev>
Subject: RE: [RFC PATCH] net: dsa: microchip: Prevent overriding of HSR port
 forwarding

> Am 15.08.25 um 00:59 schrieb Andrew Lunn:
> > On Wed, Aug 13, 2025 at 05:26:12PM +0200, Frieder Schrempf wrote:
> >> From: Frieder Schrempf <frieder.schrempf@...tron.de>
> >>
> >> The KSZ9477 supports NETIF_F_HW_HSR_FWD to forward packets between
> >> HSR ports. This is set up when creating the HSR interface via
> >> ksz9477_hsr_join() and ksz9477_cfg_port_member().
> >>
> >> At the same time ksz_update_port_member() is called on every
> >> state change of a port and reconfiguring the forwarding to the
> >> default state which means packets get only forwarded to the CPU
> >> port.
> >>
> >> If the ports are brought up before setting up the HSR interface
> >> and then the port state is not changed afterwards, everything works
> >> as intended:
> >>
> >>    ip link set lan1 up
> >>    ip link set lan2 up
> >>    ip link add name hsr type hsr slave1 lan1 slave2 lan2 supervision 45 version 1
> >>    ip addr add dev hsr 10.0.0.10/24
> >>    ip link set hsr up
> >>
> >> If the port state is changed after creating the HSR interface, this results
> >> in a non-working HSR setup:
> >>
> >>    ip link add name hsr type hsr slave1 lan1 slave2 lan2 supervision 45 version 1
> >>    ip addr add dev hsr 10.0.0.10/24
> >>    ip link set lan1 up
> >>    ip link set lan2 up
> >>    ip link set hsr up
> >
> > So, restating what i said in a different thread, what happens if only
> > software was used? No hardware offload.
> 
> Sorry, I don't understand what you are aiming at.
> 
> Yes, this issue is related to hardware offloading. As far as I know
> there is no option (for the user) to force HSR into SW-only mode. The
> KSZ9477 driver uses hardware offloading up to the capabilities of the HW
> by default.
> 
> Yes, if I disable the offloading by modifying the driver code as already
> described in the other thread, the issue can be fixed at the cost of
> loosing the HW acceleration. In this case the driver consistently
> configures the HSR ports to forward any packets to the CPU which then
> forwards them as needed.
> 
> With the driver code as-is, there are two conflicting values used for
> the register that configures the forwarding. One is set during the HSR
> setup and makes sure that HSR ports forward packets among each other
> (and not only to the CPU), the other is set while changing the link
> state of the HSR ports and causes the forwarding to only happen between
> each port and the CPU, therefore effectively disabling the HW offloading
> while the driver still assumes it is enabled.
> 
> This is obviously a problem that should be fixed in the driver as
> changing the link state of the ports *after* setup of the HSR is a
> completely valid operation that shouldn't break things like it currently
> does.

Here is a simpler fix for this problem.  If that works for you I can
submit the fix.

net: dsa: microchip: Fix HSR port setup issue

ksz9477_hsr_join() is called once to setup the HSR port membership, but
the port can be enabled later, or disabled and enabled back and the port
membership is not set correctly inside ksz_update_port_member().  The
added code always use the correct HSR port membership for HSR port that
is enabled.

Fixes: 2d61298fdd7b ("net: dsa: microchip: Enable HSR offloading for KSZ9477")
Signed-off-by: Tristram Ha <tristram.ha@...rochip.com>
---
 drivers/net/dsa/microchip/ksz_common.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 4cb14288ff0f..c04d4c895025 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -2457,6 +2457,9 @@ static void ksz_update_port_member(struct ksz_device *dev, int port)
 		dev->dev_ops->cfg_port_member(dev, i, val | cpu_port);
 	}
 
+	if (!port_member && p->stp_state == BR_STATE_FORWARDING &&
+	    (dev->hsr_ports & BIT(port)))
+		port_member = dev->hsr_ports;
 	dev->dev_ops->cfg_port_member(dev, port, port_member | cpu_port);
 }