lockdep and ww mutex debug interactions in hdmi tests

Dave Airlie airlied at gmail.com
Tue Oct 29 19:03:50 UTC 2024


Hi,

I mentioned this internally, but wanted to get it on the list,

I ran the hdmi kunit tests with LOCKDEP and WW_MUTEX_SLOWPATH enabled
and hit some issues.

With the slowpath we get the occasional EDEADLK to test the paths are
doing things right, I think you should handle EDEADLK in the tests
with a retry loop.

meanwhile lockdep said

[   64.885157] KTAP version 1
[   64.886206] 1..2
[   64.887950]     KTAP version 1
[   64.888738]     # Subtest: drm_atomic_helper_connector_hdmi_check
[   64.890271]     # module: drm_hdmi_state_helper_test
[   64.890291]     1..22

[   64.898189] ======================================================
[   64.899995] WARNING: possible circular locking dependency detected
[   64.901475] 6.12.0-rc5+ #2 Tainted: G                 N
[   64.902928] ------------------------------------------------------
[   64.904543] kunit_try_catch/1962 is trying to acquire lock:
[   64.906062] ffff502cc9c1c488 (&dev->mode_config.mutex){+.+.}-{3:3},
at: drm_test_check_broadcast_rgb_auto_cea_mode+0xb0/0x460
[drm_hdmi_state_helper_test]
[   64.909764]
               but task is already holding lock:
[   64.911408] ffff502cd0aa03f0 (crtc_ww_class_acquire){+.+.}-{0:0},
at: drm_kunit_helper_acquire_ctx_alloc+0x64/0x100 [drm_kunit_helpers]
[   64.915352]
               which lock already depends on the new lock.

[   64.917596]
               the existing dependency chain (in reverse order) is:
[   64.919596]
               -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
[   64.921408]        __lock_acquire+0x50c/0xb00
[   64.922690]        lock_acquire.part.0+0xf0/0x270
[   64.923955]        lock_acquire+0x90/0x180
[   64.925099]        drm_modeset_acquire_init+0xd4/0x138
[   64.926526]        drm_helper_probe_single_connector_modes+0x70/0x638
[   64.929138]        set_connector_edid.isra.0+0x70/0x118
[drm_hdmi_state_helper_test]
[   64.931267]
drm_atomic_helper_connector_hdmi_init+0x20c/0x3a0
[drm_hdmi_state_helper_test]
[   64.933616]
drm_test_check_broadcast_rgb_auto_cea_mode+0x50/0x460
[drm_hdmi_state_helper_test]
[   64.936099]        kunit_try_run_case+0x74/0x170 [kunit]
[   64.937518]        kunit_generic_run_threadfn_adapter+0x30/0x60 [kunit]
[   64.939325]        kthread+0x100/0x118
[   64.940364]        ret_from_fork+0x10/0x20
[   64.941513]
               -> #0 (&dev->mode_config.mutex){+.+.}-{3:3}:
[   64.943305]        check_prev_add+0x114/0x9d8
[   64.944459]        validate_chain+0x46c/0x500
[   64.946249]        __lock_acquire+0x50c/0xb00
[   64.947421]        lock_acquire.part.0+0xf0/0x270
[   64.948690]        lock_acquire+0x90/0x180
[   64.949801]        __mutex_lock+0xc0/0x430
[   64.950964]        mutex_lock_nested+0x2c/0x40
[   64.952160]
drm_test_check_broadcast_rgb_auto_cea_mode+0xb0/0x460
[drm_hdmi_state_helper_test]
[   64.954613]        kunit_try_run_case+0x74/0x170 [kunit]
[   64.956069]        kunit_generic_run_threadfn_adapter+0x30/0x60 [kunit]
[   64.957830]        kthread+0x100/0x118
[   64.958855]        ret_from_fork+0x10/0x20
[   64.960273]
               other info that might help us debug this:

[   64.962749]  Possible unsafe locking scenario:

[   64.964330]        CPU0                    CPU1
[   64.965575]        ----                    ----
[   64.966782]   lock(crtc_ww_class_acquire);
[   64.967881]                                lock(&dev->mode_config.mutex);
[   64.969841]                                lock(crtc_ww_class_acquire);
[   64.971922]   lock(&dev->mode_config.mutex);
[   64.973070]
                *** DEADLOCK ***

[   64.974634] 1 lock held by kunit_try_catch/1962:
[   64.976040]  #0: ffff502cd0aa03f0
(crtc_ww_class_acquire){+.+.}-{0:0}, at:
drm_kunit_helper_acquire_ctx_alloc+0x64/0x100 [drm_kunit_helpers]
[   64.979943]
               stack backtrace:
[   64.981136] CPU: 2 UID: 0 PID: 1962 Comm: kunit_try_catch Tainted:
G                 N 6.12.0-rc5+ #2
[   64.983577] Tainted: [N]=TEST
[   64.984356] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[   64.986202] Call trace:
[   64.986856]  dump_backtrace+0xdc/0x140
[   64.987863]  show_stack+0x20/0x40
[   64.988737]  dump_stack_lvl+0x9c/0xd0
[   64.989761]  dump_stack+0x18/0x30
[   64.990809]  print_circular_bug+0xf0/0x100
[   64.992300]  check_noncircular+0x174/0x188
[   64.993451]  check_prev_add+0x114/0x9d8
[   64.994467]  validate_chain+0x46c/0x500
[   64.995540]  __lock_acquire+0x50c/0xb00
[   64.996566]  lock_acquire.part.0+0xf0/0x270
[   64.997693]  lock_acquire+0x90/0x180
[   64.998643]  __mutex_lock+0xc0/0x430
[   64.999610]  mutex_lock_nested+0x2c/0x40
[   65.000639]  drm_test_check_broadcast_rgb_auto_cea_mode+0xb0/0x460
[drm_hdmi_state_helper_test]
[   65.002987]  kunit_try_run_case+0x74/0x170 [kunit]
[   65.004274]  kunit_generic_run_threadfn_adapter+0x30/0x60 [kunit]
[   65.006488]  kthread+0x100/0x118
[   65.007354]  ret_from_fork+0x10/0x20

Dave.


More information about the dri-devel mailing list