On Tue, Oct 18, 2022 at 3:54 PM Javier Martinez Canillas <javierm@xxxxxxxxxx> wrote: > > [adding a few folks to Cc list that might help with this issue] > > Hello Naresh, > > Thanks a lot for your report. > > On 10/18/22 08:40, Naresh Kamboju wrote: > > Following kunit tests started failing on Linux mainline. > > - drm_format_helper_test — FAIL > > - drm_test_fb_xrgb8888_to_xrgb2101010 — FAIL > > - single_pixel_source_buffer — FAIL > > > > Good: v6.0-3015-g2bca25eaeba6 > > Bad: v6.0-5118-g833477fce7a1 > > > > Could you please let me know how you are running this? I tried to reproduce it > on v6.1-rc1 with the following command but all tests passed: > > ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/tests/.kunitconfig --arch=x86_64 > [09:41:53] Configuring KUnit Kernel ... > [09:41:53] Building KUnit Kernel ... > Populating config with: > $ make ARCH=x86_64 O=.kunit olddefconfig > Building with: > $ make ARCH=x86_64 O=.kunit --jobs=8 > [09:45:51] Starting KUnit Kernel (1/1)... > [09:45:51] ============================================================ > Running tests with: > $ qemu-system-x86_64 -nodefaults -m 1024 -kernel .kunit/arch/x86/boot/bzImage -append 'kunit.enable=1 console=ttyS0 kunit_shutdown=reboot' -no-reboot -nographic -serial stdio > ... > [09:47:40] Testing complete. Ran 195 tests: passed: 195 > [09:47:40] Elapsed time: 347.817s total, 0.003s configuring, 238.009s building, 109.771s running I can reproduce this with: ./tools/testing/kunit/kunit.py run --kunitconfig drivers/gpu/drm/tests --kconfig_add CONFIG_KASAN=y --kconfig_add CONFIG_KASAN_VMALLOC=y --kconfig_add CONFIG_KASAN_KUNIT_TEST=y drm_format_helper_test.*xrgb2101010 (The issue shows up only with KASAN enabled, and it looks like there's a bug whereby KASAN failures don't trigger test failures unless CONFIG_KASAN_KUNIT_TEST=y) It looks like the issue is probably with the conversion back to le32 here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/tests/drm_format_helper_test.c#n441 That second call to le32buf_to_cpu() should probably take dst_size (or rather, dst_size / sizeof(u32)) rather than using TEST_BUF_SIZE, which is the maximum possible size of the buffer, not the actual size. That fixes it here for me, though a proper fix would avoid the division. Cheers, -- David
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
