[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e6800715-6bc0-49a0-bd00-5a75b852ea9d@lunn.ch>
Date: Fri, 31 May 2024 15:29:09 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Hans de Goede <hdegoede@...hat.com>
Cc: Linux regressions mailing list <regressions@...ts.linux.dev>,
Pavel Machek <pavel@....cz>, Lee Jones <lee@...nel.org>,
Linux LEDs <linux-leds@...r.kernel.org>,
Heiner Kallweit <hkallweit1@...il.com>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, johanneswueller@...il.com,
"Russell King (Oracle)" <linux@...linux.org.uk>,
Genes Lists <lists@...ience.com>
Subject: Re: Hung tasks due to a AB-BA deadlock between the leds_list_lock
rwsem and the rtnl mutex
> > drivers/net/ethernet/realtek/r8169_leds.c: led_cdev->hw_control_trigger = "netdev";
> > drivers/net/ethernet/realtek/r8169_leds.c: led_cdev->hw_control_trigger = "netdev";
> > drivers/net/ethernet/intel/igc/igc_leds.c: led_cdev->hw_control_trigger = "netdev";
> > drivers/net/dsa/qca/qca8k-leds.c: port_led->cdev.hw_control_trigger = "netdev";
> > drivers/net/phy/phy_device.c: cdev->hw_control_trigger = "netdev";
>
> Well those drivers combined, esp. with the generic phy_device in there
> does mean that the ledtrig-netdev module now gets loaded on a whole lot
> of x86 machines where before it would not.
phy_device will only do something if there is the needed Device Tree
properties. Given that very few systems use DT on x86, that should not
be an issue. So only x86 systems with r8169 and igc should have the
trigger module loaded because of this. It would be good to understand
why other systems have the trigger loaded. However, as you say, this
will not fix the underlying deadlock, it will just limit it to systems with r8169
and igc...
Andrew
Powered by blists - more mailing lists