linux-kernel - [PATCH 0/5] Fix a deadlock with clk_pm_runtime

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Sun, 24 Mar 2024 22:43:57 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...nel.org>
Cc: linux-kernel@...r.kernel.org,
	linux-clk@...r.kernel.org,
	patches@...ts.linux.dev,
	linux-arm-msm@...r.kernel.org,
	Douglas Anderson <dianders@...omium.org>,
	Krzysztof Kozlowski <krzk@...nel.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Taniya Das <quic_tdas@...cinc.com>,
	Ulf Hansson <ulf.hansson@...aro.org>
Subject: [PATCH 0/5] Fix a deadlock with clk_pm_runtime_get()

This patch series fixes a deadlock reported[1] on ChromeOS devices
(Qualcomm sc7180 Trogdor). To get there, we allow __clk_release() to run
without the prepare_lock held. Then we add runtime PM enabled clk_core
structs to a list that we iterate and enable runtime PM for each entry
before grabbing the prepare_lock to walk the clk tree. The details are
in patch #4.

The patch after that is based on the analysis in the disable unused
patch. We similarly resume devices from runtime suspend when walking the
clk tree for the debugfs clk_summary.

Unfortunately this doesn't fix all problems with the usage of runtime PM
in the clk framework. We still have a problem if preparing a clk happens
in parallel to the device providing that clk runtime resuming or
suspending. In that case, the task will go to sleep waiting for the
runtime PM state to change, and we'll deadlock. This is primarily a
problem with the global prepare_lock. I suspect we'll be able to fix
this by implementing per-clk locking, because then we will be able to
split up the big prepare_lock into smaller locks that don't deadlock on
some device runtime PM transitions.

I'll start working on that problem in earnest now because I'm worried
we're going to run into that problem very soon.

Stephen Boyd (5):
  clk: Remove prepare_lock hold assertion in __clk_release()
  clk: Don't hold prepare_lock when calling kref_put()
  clk: Initialize struct clk_core kref earlier
  clk: Get runtime PM before walking tree during disable_unused
  clk: Get runtime PM before walking tree for clk_summary

 drivers/clk/clk.c | 142 +++++++++++++++++++++++++++++++++++++---------
 1 file changed, 115 insertions(+), 27 deletions(-)

Cc: Douglas Anderson <dianders@...omium.org>
Cc: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Taniya Das <quic_tdas@...cinc.com>
Cc: Ulf Hansson <ulf.hansson@...aro.org>

[1] https://lore.kernel.org/all/20220922084322.RFC.2.I375b6b9e0a0a5348962f004beb3dafee6a12dfbb@changeid/

base-commit: e8f897f4afef0031fe618a8e94127a0934896aba
-- 
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git