Re: [CRASH] kunit failures in platform-device-devm

[Sasha Levin <sashal@kernel.org>]

This response was AI-generated by bug-bot. The analysis may contain errors - please verify independently.

Hi Alice,

Thanks for the detailed report. Here is my analysis.

___

1. Bug Summary

The platform-device-devm kunit test suite crashes with a general
protection fault in queued_spin_lock_slowpath() during device
registration, followed by cascading failures including sysfs duplicate
filename errors. The root issue is test isolation: earlier kunit tests
(including the intentional NULL dereference in kunit_test_null_dereference)
corrupt kernel state, and the platform-device-devm tests use raw
platform device APIs without kunit-managed cleanup, so they cannot
recover from or survive this corrupted state. The severity is a test
infrastructure issue, not a driver core bug.

2. Stack Trace Analysis

First crash (Oops #3 — two earlier oopses already occurred):

  Oops: general protection fault, probably for non-canonical address 0xb4c3c33fcc9f57f6: 0000 [#3] SMP PTI
  CPU: 0 UID: 0 PID: 2500 Comm: kunit_try_catch Tainted: G      D  W        N  7.0.0-rc1-00138-g0c21570fbd3d-dirty #3 PREEMPT(lazy)
  Tainted: [D]=DIE, [W]=WARN, [N]=TEST
  RIP: 0010:queued_spin_lock_slowpath+0x120/0x1c0
  RAX: b4c3c340405a5a26 RBX: ffffb222800e3ce8 RCX: 0000000000050000
  RDX: ffffa0a4fec1ddd0 RSI: 0000000000000010 RDI: ffffa0a4c2b43340
  Call Trace:
   <TASK>
   klist_iter_exit+0x2c/0x70
   ? __pfx___device_attach_driver+0x10/0x10
   bus_for_each_drv+0x12a/0x160
   __device_attach+0xbf/0x160
   device_initial_probe+0x2f/0x50
   bus_probe_device+0x8f/0x110
   device_add+0x23f/0x3d0
   platform_device_add+0x137/0x1d0
   platform_device_devm_register_unregister_test+0x6c/0x2e0
   kunit_try_run_case+0x8f/0x190
   kunit_generic_run_threadfn_adapter+0x1d/0x40
   kthread+0x142/0x160
   ret_from_fork+0xc7/0x1f0
   ret_from_fork_asm+0x1a/0x30
   </TASK>

The crash point is in queued_spin_lock_slowpath() at
kernel/locking/qspinlock.c, called from klist_iter_exit() at
lib/klist.c:311. RAX holds non-canonical address 0xb4c3c340405a5a26,
indicating corrupted klist data. The calling chain is process context:
platform_device_devm_register_unregister_test() calls
platform_device_add() -> device_add() -> bus_probe_device() ->
__device_attach() -> bus_for_each_drv() (drivers/base/bus.c:420)
which iterates the bus's klist_drivers. During klist_iter_exit(),
it tries to acquire the klist spinlock and hits corrupted memory.

Second failure (duplicate sysfs entry):

  sysfs: cannot create duplicate filename '/devices/platform/test'
  Call Trace:
   <TASK>
   dump_stack_lvl+0x2d/0x70
   sysfs_create_dir_ns+0xe8/0x130
   kobject_add_internal+0x1dd/0x360
   kobject_add+0x88/0xf0
   device_add+0x171/0x3d0
   platform_device_add+0x137/0x1d0
   platform_device_devm_register_get_unregister_with_devm_test+0x6c/0x2f0
   kunit_try_run_case+0x8f/0x190
   kunit_generic_run_threadfn_adapter+0x1d/0x40
   kthread+0x142/0x160
   ret_from_fork+0xc7/0x1f0
   ret_from_fork_asm+0x1a/0x30
   </TASK>

The assertion at drivers/base/test/platform-device-test.c:97 fails
with ret == -17 (EEXIST) because the first test crashed without
unregistering its device, leaving "/devices/platform/test" in sysfs.

3. Root Cause Analysis

This is a test isolation problem, not a driver core bug. Two issues
combine to cause the failures:

(a) Corrupted kernel state from earlier oopses. The Oops header shows
"[#3]" meaning this is the third kernel oops during the boot. The
taint flags [D]=DIE and [W]=WARN confirm prior fatal faults. The
kunit_test_null_dereference() function in lib/kunit/kunit-test.c:117
intentionally dereferences NULL to test kunit's fault handling. After
multiple oopses, kernel data structures (including the platform bus
klist) can be corrupted, which explains the non-canonical address
(0xb4c3c33fcc9f57f6) seen during spinlock acquisition.

(b) Missing test-managed cleanup. The four tests in
platform_device_devm_test_suite all use the raw kernel APIs
platform_device_alloc() and platform_device_add() directly, and all
use the same hardcoded name "test" with PLATFORM_DEVID_NONE
(drivers/base/test/platform-device-test.c:62-77). If a test crashes
before reaching platform_device_unregister(), the device remains
registered and subsequent tests cannot register a device with the
same name.

By contrast, the platform_device_find_by_null_test() in the same
file already uses the kunit-managed helpers kunit_platform_device_alloc()
and kunit_platform_device_add() from lib/kunit/platform.c (added in
commit 5ac79730324c "platform: Add test managed platform_device/driver
APIs"), which automatically unregister the device when the test exits,
even on crash.

4. Affected Versions

The platform-device-devm tests were introduced in commit b4cc44301b9d
("drivers: base: Add basic devm tests for platform devices") by
Maxime Ripard, which predates the kunit-managed platform device helpers
from commit 5ac79730324c. All kernel versions containing these tests
are affected by this test isolation issue. This is not a regression in
the driver core itself.

5. Relevant Commits and Fixes

- b4cc44301b9d ("drivers: base: Add basic devm tests for platform devices")
  Introduced the test suite with raw platform device APIs.

- 699fb50d99039 ("drivers: base: Free devm resources when unregistering a device")
  Fixed devm resource release for unprobed devices; updated test expectations.

- 5ac79730324c ("platform: Add test managed platform_device/driver APIs")
  Added kunit_platform_device_alloc()/kunit_platform_device_add()
  helpers that automatically clean up on test exit.

- 86a5f32ed8813 ("drivers: base: test: Add ...find_device_by...(... NULL) tests")
  Added platform_device_find_by_null_test which already uses the
  kunit-managed helpers correctly.

No fix for this specific test isolation issue exists in mainline yet.

6. Suggested Actions

The devm tests should be updated to use the kunit-managed platform
device helpers (kunit_platform_device_alloc/kunit_platform_device_add)
from include/kunit/platform_device.h, similar to how
platform_device_find_by_null_test() already does. This would ensure
proper cleanup even when tests crash.

One subtlety: the devm tests specifically test the behavior of
platform_device_unregister() releasing devm resources, so
kunit_platform_device_add() (which auto-unregisters) needs to be
used carefully — the kunit cleanup action should be removed or
disabled before the explicit unregister call to avoid double-free.
Alternatively, each test could use a unique device name via
PLATFORM_DEVID_AUTO to at least prevent the cascading sysfs duplicate
errors.

For the probed tests (probed_platform_device_devm_register_unregister_test
and probed_platform_device_devm_register_get_unregister_with_devm_test),
there is a similar need to register/unregister the fake_driver with
kunit-managed helpers like kunit_platform_driver_register().

In the short term, you can work around this by running the
platform-device-devm suite in isolation:

  ./tools/testing/kunit/kunit.py run --make_options LLVM=1 \
    --arch x86_64 --kconfig_add CONFIG_RUST=y \
    --kconfig_add CONFIG_PCI=y platform-device-devm

This avoids the corrupted state from earlier intentional-crash tests.