diff options
author | Luca Coelho <luciano.coelho@intel.com> | 2025-02-03 15:31:13 +0200 |
---|---|---|
committer | Lucas De Marchi <lucas.demarchi@intel.com> | 2025-08-25 08:42:46 -0700 |
commit | e9b01b51c8625afc2f18bf3a91db2b8f2c68a751 (patch) | |
tree | 45eb00afc0ab2efe96d252ea1871670df81505d3 /kernel/time/vsyscall.c | |
parent | 6b3c68c7f314d958f1ffbc9ec5fc4ad62873bb13 (diff) |
Revert "lockdep: Enable PROVE_RAW_LOCK_NESTING with PROVE_LOCKING."
This reverts commit 560af5dc839eef08a273908f390cfefefb82aa04.
Locking in i915_pmu.c interacting with perf is completely wrong. It's
using spinlock_t everywhere when it should actually use raw_spinlock_t
since perf is already holding raw_spinlock in the caller. This started
to be checked with commit 560af5dc839e ("lockdep: Enable
PROVE_RAW_LOCK_NESTING with PROVE_LOCKING."), but should only be a real
issue when PREEMPT_RT is enabled: in that config, the spinlock_t can
sleep and creates issue.
Reworking the locks in i915_pmu.c is not very simple as changing locks
to raw_spinlock_t cascades to too many locks, which is both a) not
desired from an RT perspective and b) hard to get right as it calls into
other parts of the driver that have other requirements.
Example backtrace:
<4> [141.043897] =============================
<4> [141.043922] [ BUG: Invalid wait context ]
<4> [141.043940] 6.13.0-rc2-CI_DRM_15820-g78bd7a249aa0+ #1 Not tainted
<4> [141.043964] -----------------------------
<4> [141.043981] swapper/0/0 is trying to lock:
<4> [141.044000] ffff88810861b910 (&pmu->lock){....}-{3:3}, at: i915_pmu_enable+0x48/0x3a0 [i915]
<4> [141.044194] other info that might help us debug this:
<4> [141.044217] context-{5:5}
<4> [141.044229] 1 lock held by swapper/0/0:
<4> [141.044248] #0: ffff88885f432038 (&cpuctx_lock){....}-{2:2}, at: __perf_install_in_context+0x3f/0x360
<4> [141.044297] stack backtrace:
<4> [141.044312] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc2-CI_DRM_15820-g78bd7a249aa0+ #1
<4> [141.044353] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024
<4> [141.044405] Call Trace:
<4> [141.044419] <TASK>
<4> [141.044431] dump_stack_lvl+0x91/0xf0
<4> [141.044454] dump_stack+0x10/0x20
<4> [141.044472] __lock_acquire+0x990/0x2820
<4> [141.044498] lock_acquire+0xc9/0x300
<4> [141.044518] ? i915_pmu_enable+0x48/0x3a0 [i915]
<4> [141.044689] _raw_spin_lock_irqsave+0x49/0x80
<4> [141.044713] ? i915_pmu_enable+0x48/0x3a0 [i915]
<4> [141.044903] i915_pmu_enable+0x48/0x3a0 [i915]
<4> [141.045112] ? __lock_acquire+0x455/0x2820
<4> [141.045142] i915_pmu_event_add+0x71/0x90 [i915]
More time is needed to get this fixed properly, but let's not pile
regressions on top.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241211121703.2890150-1-luciano.coelho@intel.com
[ Reword commit message, giving more detail on what the issue is ]
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
References: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13311
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Diffstat (limited to 'kernel/time/vsyscall.c')
0 files changed, 0 insertions, 0 deletions