Messages in this thread | | | Date | Tue, 16 Nov 2021 15:04:19 +0100 | From | Greg Kroah-Hartman <> | Subject | Re: [PATCH 5.14 232/849] leds: trigger: use RCU to protect the led_cdevs list |
| |
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
| |