Messages in this thread Patch in this message | | | From | Mark Brown <> | Subject | Applied "regulator: core: Avoid potential deadlock on regulator_unregister" to the regulator tree | Date | Fri, 5 Apr 2019 09:43:42 +0700 (+07) |
| |
The patch
regulator: core: Avoid potential deadlock on regulator_unregister
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
From 063773011d33bb36588a90385aa9eb75d13c6d80 Mon Sep 17 00:00:00 2001 From: Charles Keepax <ckeepax@opensource.cirrus.com> Date: Thu, 4 Apr 2019 16:32:18 +0100 Subject: [PATCH] regulator: core: Avoid potential deadlock on regulator_unregister
Lockdep reports the following issue on my setup:
Possible unsafe locking scenario:
CPU0 CPU1 ---- ---- lock((work_completion)(&(&rdev->disable_work)->work)); lock(regulator_list_mutex); lock((work_completion)(&(&rdev->disable_work)->work)); lock(regulator_list_mutex);
The problem is that regulator_unregister takes the regulator_list_mutex and then calls flush_work on disable_work. But regulator_disable_work calls regulator_lock_dependent which will also take the regulator_list_mutex. Resulting in a deadlock if the flush_work call actually needs to flush the work.
Fix this issue by moving the flush_work outside of the regulator_list_mutex. The list mutex is not used to guard the point at which the delayed work is queued, so its use adds no additional safety.
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> --- drivers/regulator/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 968dcd9d7a07..8573dd0871fd 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -5061,10 +5061,11 @@ void regulator_unregister(struct regulator_dev *rdev) regulator_put(rdev->supply); } + flush_work(&rdev->disable_work.work); + mutex_lock(®ulator_list_mutex); debugfs_remove_recursive(rdev->debugfs); - flush_work(&rdev->disable_work.work); WARN_ON(rdev->open_count); regulator_remove_coupling(rdev); unset_regulator_supplies(rdev); -- 2.20.1
| |