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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250813155452.55c4eb81@wsk>
Date: Wed, 13 Aug 2025 15:54:52 +0200
From: Ɓukasz Majewski <lukma@...ladev.com>
To: Frieder Schrempf <frieder.schrempf@...tron.de>
Cc: Woojung.Huh@...rochip.com, kuba@...nel.org, andrew@...n.ch,
 netdev@...r.kernel.org, Tristram.Ha@...rochip.com
Subject: Re: KSZ9477 HSR Offloading

Hi Frieder,

> Am 04.02.25 um 15:55 schrieb Woojung.Huh@...rochip.com:
> > Hi Jakub,
> >   
> >> -----Original Message-----
> >> From: Jakub Kicinski <kuba@...nel.org>
> >> Sent: Monday, February 3, 2025 6:04 PM
> >> To: Woojung Huh - C21699 <Woojung.Huh@...rochip.com>
> >> Cc: frieder.schrempf@...tron.de; lukma@...x.de; andrew@...n.ch;
> >> netdev@...r.kernel.org; Tristram Ha - C24268
> >> <Tristram.Ha@...rochip.com> Subject: Re: KSZ9477 HSR Offloading
> >>
> >> EXTERNAL EMAIL: Do not click links or open attachments unless you
> >> know the content is safe
> >>
> >> On Mon, 3 Feb 2025 14:58:12 +0000 Woojung.Huh@...rochip.com wrote:
> >>  
> >>> Hi Lukasz & Frieder,
> >>>
> >>> Oops! My bad. I confused that Lukasz was filed a case originally.
> >>> Monday  
> >> brain-freeze. :(  
> >>>
> >>> Yes, it is not a public link and per-user case. So, only Frieder
> >>> can see  
> >> it.  
> >>> It may be able for you when Frieder adds you as a team. (Not
> >>> tested  
> >> personally though)
> >>
> >> Woojung Huh, please make sure the mailing list is informed about
> >> the outcomes. Taking discussion off list to a closed ticketing
> >> system is against community rules. See below, thanks.
> >>
> >> Quoting documentation:
> >>
> >>   Open development
> >>   ----------------
> >>
> >>   Discussions about user reported issues, and development of new
> >> code should be conducted in a manner typical for the larger
> >> subsystem. It is common for development within a single company to
> >> be conducted behind closed doors. However, development and
> >> discussions initiated by community members must not be redirected
> >> from public to closed forums or to private email conversations.
> >> Reasonable exceptions to this guidance include discussions about
> >> security related issues.
> >>
> >> See:
> >> https://www.kernel.org/doc/html/next/maintainer/feature-and-driver-maintainers.html#open-development
> >>  
> > 
> > Learn new thing today. Didn't know this. Definitely I will share it
> > when this work is done. My intention was for easier work for
> > request than having me as an middleman for the issue.  
> 
> Here is a follow-up for this thread. I was busy elsewhere, didn't have
> access to the hardware and failed to respond to the comments from
> Microchip support team provided in their internal ticket system.
> 
> As a summary, the Microchip support couldn't reproduce my issue on
> their side and asked for further information.
> 
> With the hardware now back on my table I was able to do some further
> investigations and found out that this is caused by a misconfiguration
> on my side, that doesn't get handled/prevented by the kernel.

If I remember correctly from the ticket - there was also an issue with
the size of MTU for HSR packets.

Am I correct?

> 
> The HW forwarding between HSR ports is configured in
> ksz9477_hsr_join() at the time of creating the HSR interface by
> calling ksz9477_cfg_port_member().
> 
> In my case I enabled the ports **after** that which caused the
> forwarding to be disabled again as ksz9477_cfg_port_member() gets
> called with the default configuration.
> 
> If I reorder my commands everything seems to work fine even with
> NETIF_F_HW_HSR_FWD enabled.
> 
> I wonder if the kernel should handle this case and prevent the
> forwarding configuration to be disabled if HSR is configured? I'll
> have a look if I can come up with a patch for this.
> 

Thanks  for looking for this issue. I'm looking forward for your
patches.

-- 
Best regards,

Lukasz Majewski

--
Nabla Software Engineering GmbH
HRB 40522 Augsburg
Phone: +49 821 45592596
E-Mail: office@...ladev.com
Geschftsfhrer : Stefano Babic

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ