Hi Catalin, On Wed, Apr 16, 2025 at 10:34:05AM +0100, Catalin Marinas wrote: > On Thu, Feb 20, 2025 at 02:25:37PM +0100, Maxime Ripard wrote: > > lockdep complains when a lock is released in a separate thread the > > lock is taken in, and it turns out that kunit does run its actions in a > > separate thread than the test ran in. > > > > This means that drm_kunit_helper_acquire_ctx_alloc() just cannot work as > > it's supposed to, so let's just get rid of it. > > > > Suggested-by: Simona Vetter <simona.vet...@ffwll.ch> > > Reviewed-by: Dmitry Baryshkov <dmitry.barysh...@linaro.org> > > Signed-off-by: Maxime Ripard <mrip...@kernel.org> > > My scripts for running all possible kunit tests (under arm64 qemu) > started failing with 6.15-rc1. I bisected it to commit 30188df0c387 > ("drm/tests: Drop drm_kunit_helper_acquire_ctx_alloc()"). No idea > whether it fails on other architectures but it's fairly easy to > reproduce on arm64. Starting from defconfig, enable CONFIG_KUNIT=m and > CONFIG_DRM_VC4_KUNIT_TEST=m, build the kernel with gcc. Once a prompt is > reached, "modprobe vc4" and the most noticeable thing is the kernel > panic with stack protector enabled (by default on arm64): > > Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: > drm_vc4_test_pv_muxing+0x2a4/0x2a4 [vc4] > CPU: 14 UID: 0 PID: 311 Comm: kunit_try_catch Tainted: G W N > 6.15.0-rc2 #1 PREEMPT > Tainted: [W]=WARN, [N]=TEST > Hardware name: QEMU KVM Virtual Machine, BIOS 2024.08-4 10/25/2024 > Call trace: > show_stack+0x18/0x24 (C) > dump_stack_lvl+0x60/0x80 > dump_stack+0x18/0x24 > panic+0x168/0x360 > __ktime_get_real_seconds+0x0/0x20 > vc4_test_pv_muxing_gen_params+0x0/0x94 [vc4] > kunit_try_run_case+0x6c/0x160 [kunit] > kunit_generic_run_threadfn_adapter+0x28/0x4c [kunit] > kthread+0x12c/0x204 > ret_from_fork+0x10/0x20 > SMP: stopping secondary CPUs > Kernel Offset: 0x431a85f00000 from 0xffff800080000000 > PHYS_OFFSET: 0xfff0e8f3c0000000 > CPU features: 0x0002,00000268,01002640,82004203 > Memory Limit: none > ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is > corrupted in: drm_vc4_test_pv_muxing+0x2a4/0x2a4 [vc4] ]--- > > Scrolling through the log, I also get a lot of warnings before the > panic: > > WARNING: CPU: 14 PID: 311 at drivers/gpu/drm/drm_modeset_lock.c:296 > drm_modeset_lock+0xbc/0xfc [drm] > Modules linked in: vc4 snd_soc_hdmi_codec drm_kunit_helpers drm_exec cec > drm_display_helper drm_client_lib drm_dma_helper kunit drm_kms_helper drm > backlight dm_mod ip_tables x_tables ipv6 > CPU: 14 UID: 0 PID: 311 Comm: kunit_try_catch Tainted: G W N > 6.15.0-rc2 #1 PREEMPT > Tainted: [W]=WARN, [N]=TEST > Hardware name: QEMU KVM Virtual Machine, BIOS 2024.08-4 10/25/2024 > pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > pc : drm_modeset_lock+0xbc/0xfc [drm] > lr : drm_atomic_get_private_obj_state+0x78/0x180 [drm] > sp : ffff800080b0bbd0 > x29: ffff800080b0bbd0 x28: 0000000000000004 x27: ffff170d4829a480 > x26: ffff170d42968000 x25: ffff170d4829a480 x24: ffff170d40eaf540 > x23: 0000000000000038 x22: ffff170d42964400 x21: ffff170d4829a480 > x20: ffff170d42968958 x19: ffff800080b0bd58 x18: 00000000ffffffff > x17: 0000000000000000 x16: ffffc31b065888a0 x15: 0000000000000000 > x14: 0000000000000040 x13: 01e0000002800280 x12: 0000000000000000 > x11: 0000000000000000 x10: 000001e001e001e0 x9 : 0000000000000020 > x8 : ffff170d40b70148 x7 : 0000000000000021 x6 : 0000000000000fdf > x5 : 0000000000000fdf x4 : 0000000000000004 x3 : ffff170d429688f0 > x2 : ffff170d40eaf540 x1 : 0000000000000000 x0 : ffff800080b0be10 > Call trace: > drm_modeset_lock+0xbc/0xfc [drm] (P) > drm_atomic_get_private_obj_state+0x78/0x180 [drm] > vc4_atomic_check+0x47c/0x754 [vc4] > drm_atomic_check_only+0x4d4/0x914 [drm] > drm_vc4_test_pv_muxing+0xe0/0x2a4 [vc4] > kunit_try_run_case+0x6c/0x160 [kunit] > kunit_generic_run_threadfn_adapter+0x28/0x4c [kunit] > kthread+0x12c/0x204 > ret_from_fork+0x10/0x20 > > Reverting the above commit makes these go away. I did not have time to > look deeper, I thought I'd report it here first. > > The panic is with gcc 14.2.0 from Debian unstable. I tried with gcc > 12.2.0 in Debian stable and I don't get the stack protector panic, only > the lock warnings. > > With clang 14 and 19, I get NULL pointer dereferences with this call > trace (decoded): > > Unable to handle kernel NULL pointer dereference at virtual address > 0000000000000008 > [...] > drm_modeset_lock (include/linux/list.h:153 include/linux/list.h:169 > drivers/gpu/drm/drm_modeset_lock.c:318 > drivers/gpu/drm/drm_modeset_lock.c:396) drm (P) > drm_atomic_get_connector_state (drm.mod.c:?) drm > vc4_mock_atomic_add_output (drivers/gpu/drm/vc4/tests/vc4_mock_output.c:?) > vc4 > drm_vc4_test_pv_muxing (drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c:688) > vc4 > kunit_try_run_case (lib/kunit/test.c:400) kunit > kunit_generic_run_threadfn_adapter (lib/kunit/try-catch.c:31) kunit > kthread (kernel/kthread.c:466) > ret_from_fork (arch/arm64/kernel/entry.S:863) > > I can run more tests if you'd like, decode the stack traces.
Sorry I couldn't get to this sooner, and thanks for the awesome report. I've just sent a fix, let me know if it also works for you: https://lore.kernel.org/dri-devel/20250520-drm-vc4-kunit-fixes-v1-1-ca281e485...@kernel.org/ Maxime
signature.asc
Description: PGP signature