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: <b4ba27e5-a1cc-4477-a254-a318e586ef2a@mailbox.org>
Date: Mon, 17 Nov 2025 12:18:31 +0100
From: Marek Vasut <marek.vasut@...lbox.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: linux-leds@...r.kernel.org,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Christian Marangi <ansuelsmth@...il.com>,
 Christophe Roullier <christophe.roullier@...s.st.com>,
 Daniel Golle <daniel@...rotopia.org>, Heiner Kallweit
 <hkallweit1@...il.com>, Lee Jones <lee@...nel.org>,
 Pavel Machek <pavel@....cz>, kernel@...electronics.com,
 linux-stm32@...md-mailman.stormreply.com, netdev@...r.kernel.org
Subject: Re: [PATCH] leds: trigger: netdev: Check offload ability on interface
 up

On 10/3/24 2:47 AM, Marek Vasut wrote:

Hello again,

>>> On STM32MP13xx with RTL8211F, it is enough to have the following udev 
>>> rule
>>> in place, boot the machine with cable plugged in, and the LEDs won't 
>>> work
>>> without this patch once the interface is brought up, even if they 
>>> should:
>>> "
>>> ACTION=="add", SUBSYSTEM=="leds", KERNEL=="stmmac-0:01:green:wan", 
>>> ATTR{trigger}="netdev", ATTR{link_10}="1", ATTR{link_100}="1", 
>>> ATTR{link_1000}="1", ATTR{device_name}="end0"
>>> ACTION=="add", SUBSYSTEM=="leds", KERNEL=="stmmac-0:01:yellow:wan", 
>>> ATTR{trigger}="netdev", ATTR{rx}="1", ATTR{tx}="1", ATTR{device_name} 
>>> ="end0"
>>> "
>>
>> Nice use of udev. I had not thought about using it for this.

I might have been a bit too hasty with this. The following is only a 
quick preliminary FYI, I am still investigating the details.

I observe on 6.18-rc6 (ST STM32MP13xx , so STM32 DWMAC ethernet, and 
RTL8211F PHY), that if I use the these udev rules (SoC has two MACs, 
there are two rules for each MAC, and 2 rules for each of two LEDs on 
each MAC PHY , therefore four rules in total ; the rules for both MACs 
are identical):

"
ACTION=="add|change", SUBSYSTEM=="leds", 
KERNEL=="stmmac-0:01:green:wan", ATTR{trigger}="netdev", 
ATTR{link_10}="1", ATTR{link_100}="1", ATTR{link_1000}="1", 
ATTR{device_name}="ethsom0"
ACTION=="add|change", SUBSYSTEM=="leds", 
KERNEL=="stmmac-0:01:yellow:wan", ATTR{trigger}="netdev", ATTR{rx}="1", 
ATTR{tx}="1", ATTR{device_name}="ethsom0"

ACTION=="add|change", SUBSYSTEM=="leds", 
KERNEL=="stmmac-1:01:green:lan", ATTR{trigger}="netdev", 
ATTR{link_10}="1", ATTR{link_100}="1", ATTR{link_1000}="1", 
ATTR{device_name}="ethsom1"
ACTION=="add|change", SUBSYSTEM=="leds", 
KERNEL=="stmmac-1:01:yellow:lan", ATTR{trigger}="netdev", ATTR{rx}="1", 
ATTR{tx}="1", ATTR{device_name}="ethsom1"
"

I get this backtrace. Notice the "sysfs: cannot create duplicate 
filename ..." part , I suspect there is some subtle race condition ?

"
sysfs: cannot create duplicate filename 
'/devices/platform/soc/5c007000.bus/5800e000.ethernet/mdio_bus/stmmac-1/stmmac-1:01/leds/stmmac-1:01:green:lan/link_10'
CPU: 0 UID: 0 PID: 153 Comm: (udev-worker) Not tainted 6.18.0-rc6 #1 
PREEMPT
Hardware name: STM32 (Device Tree Support)
Call trace:
  unwind_backtrace from show_stack+0x18/0x1c
  show_stack from dump_stack_lvl+0x54/0x68
  dump_stack_lvl from sysfs_warn_dup+0x58/0x6c
  sysfs_warn_dup from sysfs_add_file_mode_ns+0xf0/0x130
  sysfs_add_file_mode_ns from internal_create_group+0x344/0x480
  internal_create_group from internal_create_groups+0x48/0x6c
  internal_create_groups from led_trigger_set+0x1e4/0x278
  led_trigger_set from led_trigger_write+0xe0/0x118
  led_trigger_write from sysfs_kf_bin_write+0x98/0xa0
  sysfs_kf_bin_write from kernfs_fop_write_iter+0x14c/0x198
  kernfs_fop_write_iter from vfs_write+0x170/0x1d4
  vfs_write from ksys_write+0x7c/0xd0
  ksys_write from ret_fast_syscall+0x0/0x54
Exception stack(0xedbf1fa8 to 0xedbf1ff0)
1fa0:                   00000006 bec4476c 00000015 bec4476c 00000006 
00000001
1fc0: 00000006 bec4476c 000e7698 00000004 00000006 fffffff7 00000000 
000d1710
1fe0: 00000004 bec44578 b6c34397 b6bb15e6
leds stmmac-1:01:green:lan: Failed to add trigger attributes
"

If I find out more, I will get back to this thread.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ