summaryrefslogtreecommitdiff
path: root/rust/zerocopy/git@git.tavy.me:linux-stable.git
diff options
context:
space:
mode:
authorTimur Tabi <ttabi@nvidia.com>2026-07-08 18:57:22 -0500
committerMark Brown <broonie@kernel.org>2026-07-09 01:41:17 +0100
commitd38f8bd771c4999b797d7074b348cf201414bd34 (patch)
tree42556fd7301746c4a2ba9fbee788ee61ef99adc1 /rust/zerocopy/git@git.tavy.me:linux-stable.git
parent87063bab451963c2e424154437cd14c926127c42 (diff)
regulator: core: regulator_lock_two() should test for EDEADLK not EDEADLOCK
Compare against -EDEADLK, which is what ww_mutex_lock() actually returns and what every other deadlock check in this file already uses. Function regulator_lock_two() acquires two regulators via regulator_lock_nested() -> ww_mutex_lock(). On contention, ww_mutex_lock() returns -EDEADLK, which is the caller's signal to drop the lock it holds and retry the acquisition in the canonical order. However, regulator_lock_two() tests the return value against -EDEADLOCK rather than -EDEADLK. On most architectures, EDEADLK and EDEADLOCK are the same value, so the comparison happens to be correct and the bug is invisible. But on MIPS, SPARC, and PowerPC, those two errors have different values. The test is wrong: a genuine -EDEADLK backoff no longer matches -EDEADLOCK, so instead of unlocking and retrying, the code falls into WARN_ON(ret) and returns with only one of the two regulators locked. In practice, this is a bug only on MIPS, because the regulator core is not built or used on the other two platforms. In general, EDEADLK is preferred over EDEADLOCK for new code. Fixes: cba6cfdc7c3f ("regulator: core: Avoid lockdep reports when resolving supplies") Signed-off-by: Timur Tabi <ttabi@nvidia.com> Link: https://patch.msgid.link/20260708235722.2953579-1-ttabi@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'rust/zerocopy/git@git.tavy.me:linux-stable.git')
0 files changed, 0 insertions, 0 deletions