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

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: <d520f61e-1c51-48dd-aa49-6bf4618d6b54@mailbox.org>
Date: Wed, 19 Nov 2025 17:09:30 +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,
 Vladimir Oltean <vladimir.oltean@....com>
Subject: 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,

>>>> 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.