Re: [PATCH] leds: trigger: netdev: Check offload ability on interface up

On 11/17/25 12:18 PM, Marek Vasut wrote:

Hello one more time,

quoted

quoted

quoted

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.

I've been tracking it all the way to kernfs, but so far without much 
success.

I found commit 52c47742f79d ("leds: triggers: send uevent when changing 
triggers") which indicates the udev rules above are likely wrong, but 
they still shouldn't corrupt sysfs the way they do, right ?

If you have any hint how to find out what is actually going on, I would 
be much grateful. I already tried KASAN on this and LOCKDEP, but neither 
triggers. I was also adding a lot of trace_printk() into netdev LED 
trigger, but all I could find is the link_* attributes are removed, then 
added again, and the kernel complains the link_10 attribute already exists.

I also noticed that if I try to list /sys/...stmmac-1:01:green:lan/ 
directory after the splat with netdev trigger set, the result of the 
listing is not always the same, sometimes there are the netdev trigger 
attributes, sometimes not, and sometimes they are corrupted.