[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <73d37ff63ee7cd88772fc0767f4474317b56a0a8.camel@sapience.com>
Date: Thu, 30 May 2024 12:23:48 -0400
From: Genes Lists <lists@...ience.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: linux-kernel@...r.kernel.org, netdev@...r.kernel.org, andrew@...n.ch,
hkallweit1@...il.com, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, johanneswueller@...il.com, Thorsten
Leemhuis <linux@...mhuis.info>
Subject: Re: 6.9.3 Hung tasks
On Thu, 2024-05-30 at 15:04 +0100, Russell King (Oracle) wrote:
> ...
> And then we get to pid 858. This is in set_device_name(), which
> was called from led_trigger_set() and led_trigger_register().
> We know from pid 663 that led_trigger_register() can take a read
> on leds_list_lock, and indeed it does and then calls
> led_match_default_trigger(), which then goes on to call
> led_trigger_set(). Bingo, this is why pid 666 is blocked, which
> then blocks pid 663. pid 663 takes the rtnl lock, which blocks
> everything else _and_ also blocks pid 858 in set_device_name().
>
> Lockdep would've found this... this is a classic AB-BA deadlock
> between the leds_list_lock rwsem and the rtnl mutex.
>
> I haven't checked to see how that deadlock got introduced, that's
> for someone else to do.
>
Thank you for the analysis - hopefully someone can track down the
culprit.
cc: thorsten
--
Gene
Content of type "text/html" skipped
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists