On Tue, Nov 16, 2021 at 12:41:47PM +0100, Pavel Machek wrote:
On Mon 2021-11-15 17:55:15, Greg Kroah-Hartman wrote:
From: Johannes Berg johannes.berg@intel.com
[ Upstream commit 2a5a8fa8b23144d14567d6f8293dd6fbeecee393 ]
Even with the previous commit 27af8e2c90fb ("leds: trigger: fix potential deadlock with libata") to this file, we still get lockdep unhappy, and Boqun explained the report here: https://lore.kernel.org/r/YNA+d1X4UkoQ7g8a@boqun-archlinux
Effectively, this means that the read_lock_irqsave() isn't enough here because another CPU might be trying to do a write lock, and thus block the readers.
This is all pretty messy, but it doesn't seem right that the LEDs framework imposes some locking requirements on users, in particular we'd have to make the spinlock in the iwlwifi driver always disable IRQs, even if we don't need that for any other reason, just to avoid this deadlock.
Since writes to the led_cdevs list are rare (and are done by userspace), just switch the list to RCU. This costs a synchronize_rcu() at removal time so we can ensure things are correct, but that seems like a small price to pay for getting lock-free iterations and no deadlocks (nor any locking requirements imposed on users.)
Signed-off-by: Johannes Berg johannes.berg@intel.com Signed-off-by: Pavel Machek pavel@ucw.cz Signed-off-by: Sasha Levin sashal@kernel.org
Please drop. We discussed this with Johannes, and it was not marked for stable on purpose. Bug is rather obscure and change did not have enough testing.
Now dropped from 5.14.y and 5.15.y
thanks,
greg k-h