netdev - 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: <a45178cf-304d-4fab-bb10-7621296661fe@kontron.de>
Date: Mon, 18 Aug 2025 13:00:59 +0200
From: Frieder Schrempf <frieder.schrempf@...tron.de>
To: Tristram.Ha@...rochip.com, 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, 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

Hi Tristram,

Am 16.08.25 um 02:53 schrieb Tristram.Ha@...rochip.com:
>> 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);
>  }
> 

This looks fantastic! Way better than my approach!

I just tested it and it seems to fix the issue for me. Please send this
as formal patch and put me in Reported-by.

You might also want to add a comment in the code that gives a short
explanation for this.

Thanks
Frieder