linux-kernel - Re: [EXT] Re: [RFC PATCH net-next] net: hsr: create an API to get hsr port type

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: <20250825155556.fehgly3ggkydgbgw@skbuf>
Date: Mon, 25 Aug 2025 18:55:56 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Xiaoliang Yang <xiaoliang.yang_1@....com>
Cc: Lukasz Majewski <lukma@...x.de>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"n.zhandarovich@...tech.ru" <n.zhandarovich@...tech.ru>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"horms@...nel.org" <horms@...nel.org>,
	"m-karicheri2@...com" <m-karicheri2@...com>
Subject: Re: [EXT] Re: [RFC PATCH net-next] net: hsr: create an API to get
 hsr port type

Hi Xiaoliang,

On Thu, Jul 24, 2025 at 01:54:51PM +0300, Xiaoliang Yang wrote:
> Hi Lukasz,
> 
> > 
> > Hi Xiaoliang,
> > 
> > > If a switch device has HSR hardware ability and HSR configuration
> > > offload to hardware. The device driver needs to get the HSR port type
> > > when joining the port to HSR. Different port types require different
> > > settings for the hardware, like HSR_PT_SLAVE_A, HSR_PT_SLAVE_B, and
> > > HSR_PT_INTERLINK. Create the API hsr_get_port_type() and export it.
> > >
> > 
> > Could you describe the use case in more detail - as pointed out by Vladimir?
> > 
> > In my use case - when I use the KSZ9477 switch I just provide correct arguments
> > for the iproute2 configuration:
> > 
> > # Configuration - RedBox (EVB-KSZ9477):
> > if link set lan1 down;ip link set lan2 down ip link add name hsr0 type hsr slave1
> > lan1 slave2 lan2 supervision 45
> > 	 version 1
> > ip link add name hsr1 type hsr slave1 lan4 slave2 lan5 interlink lan3
> > 	supervision 45 version 1
> > ip link set lan4 up;ip link set lan5 up
> > ip link set lan3 up
> > ip addr add 192.168.0.11/24 dev hsr1
> > ip link set hsr1 up
> > 
> > # Configuration - DAN-H (EVB-KSZ9477):
> > ip link set lan1 down;ip link set lan2 down ip link add name hsr0 type hsr slave1
> > lan1 slave2 lan2 supervision 45
> > 	version 1
> > ip link add name hsr1 type hsr slave1 lan4 slave2 lan5 supervision 45
> > 	version 1
> > ip link set lan4 up;ip link set lan5 up
> > ip addr add 192.168.0.12/24 dev hsr1
> > ip link set hsr1 up
> > 
> > More info (also regarding HSR testing with QEMU) can be found from:
> > https://lpc.events/event/18/contributions/1969/attachments/1456/3092/lpc-
> > 2024-HSR-v1.0-e26d140f6845e94afea.pdf
> > 
> > 
> > As fair as I remember - the Node Table can be read from debugfs.
> > 
> > However, such approach has been regarded as obsolete - by the community.
> > 
> > In the future development plans there was the idea to use netlink (or iproute
> > separate program) to get the data now available in debugfs and extend it to also
> > print REDBOX node info (not only DANH).
> > 
> I need to offload the NETIF_F_HW_HSR_TAG_INS and NETIF_F_HW_HSR_TAG_RM
> to hardware. The hardware needs to know which ports are slave ports, which is
> interlink port.
> 
> Hardware remove HSR tag on interlink port if it is egress port, keep the HSR tag 
> on HSR slave ports. The frames from ring network are removed HSR tag and 
> forwarded to interlink port in hardware, not received in HSR stack.
> 
> Thanks,
> Xiaoliang

Sorry for the delay, but I remembered just now that there exists an use
case for which hsr_get_port_type() can already be added to the kernel,
without the need for submitting a new driver.

The discussion is here:
https://lore.kernel.org/netdev/20240620090210.drop6jwh7e5qw556@skbuf/
the basic idea is that the xrs700x.c driver only supports offloading
HSR_PT_SLAVE_A and HSR_PT_SLAVE_B (which were the only port types at the
time the offload for this driver was written). However, the API does not
explicitly tell it what port has what role. The driver can get confused
and think that it can support a configuration which it actually can't
(see the table in the link attached, and the xrs700x_hsr_join() function).
The only way to solve that is to introduce an API for the HSR port type
and use it in the xrs700x driver.

Would you be willing to resend this patch, making xrs700x_hsr_join() the
first user?

Actually I think it can be considered a bug fix worthwile of backporting
to stable kernels (unsupported configuration fails to be rejected), with
Fixes: 5055cccfc2d1 ("net: hsr: Provide RedBox support (HSR-SAN)")