summaryrefslogtreecommitdiffstats
path: root/fs/btrfs
diff options
context:
space:
mode:
authorJohannes Berg <johannes.berg@intel.com>2021-09-15 18:16:01 +0200
committerPavel Machek <pavel@ucw.cz>2021-09-27 16:16:42 +0200
commit2a5a8fa8b23144d14567d6f8293dd6fbeecee393 (patch)
treecfbcb7cb2c23665ecc400bac2cc29d21f4fe40b5 /fs/btrfs
parent811b5440c6e4998755990fd2c1455f42f3aae3b0 (diff)
downloadlinux-stable-2a5a8fa8b23144d14567d6f8293dd6fbeecee393.tar.gz
linux-stable-2a5a8fa8b23144d14567d6f8293dd6fbeecee393.tar.bz2
linux-stable-2a5a8fa8b23144d14567d6f8293dd6fbeecee393.zip
leds: trigger: use RCU to protect the led_cdevs list
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>
Diffstat (limited to 'fs/btrfs')
0 files changed, 0 insertions, 0 deletions