netdev - Re: KSZ9477 HSR Offloading

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: <8e761c31-728c-4ff7-925a-5e16a9ef1310@kontron.de>
Date: Wed, 13 Aug 2025 15:43:14 +0200
From: Frieder Schrempf <frieder.schrempf@...tron.de>
To: Woojung.Huh@...rochip.com, kuba@...nel.org
Cc: lukma@...x.de, andrew@...n.ch, netdev@...r.kernel.org,
 Tristram.Ha@...rochip.com
Subject: Re: KSZ9477 HSR Offloading

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.

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.