On Wed, Oct 19, 2022 at 03:32:40PM +0800, David Gow wrote: > The xrgb2101010 format conversion test (unlike for other formats) does > an endianness conversion on the results. However, it always converts > TEST_BUF_SIZE 32-bit integers, which results in reading from (and > writing to) more memory than in present in the result buffer. Instead, > use the buffer size, divided by sizeof(u32). > > The issue could be reproduced with KASAN: > ./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 > > Reported-by: Linux Kernel Functional Testing <lkft@xxxxxxxxxx> > Fixes: 453114319699 ("drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_xrgb2101010()") > Signed-off-by: David Gow <davidgow@xxxxxxxxxx> > --- > > This is a fix for the issue reported here: > https://lore.kernel.org/dri-devel/CA+G9fYsuc9G+RO81E=vHMqxYStsmLURLdOB0NF26kJ1=K8pRZA@xxxxxxxxxxxxxx/ > > Note that it may conflict with the KUNIT_EXPECT_MEMEQ() series here: > https://lore.kernel.org/linux-kselftest/20221018190541.189780-1-mairacanal@xxxxxxxxxx/ > > Cheers, > -- David > > --- > drivers/gpu/drm/tests/drm_format_helper_test.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c b/drivers/gpu/drm/tests/drm_format_helper_test.c > index 8d86c250c2ec..2191e57f2297 100644 > --- a/drivers/gpu/drm/tests/drm_format_helper_test.c > +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c > @@ -438,7 +438,7 @@ static void drm_test_fb_xrgb8888_to_xrgb2101010(struct kunit *test) > iosys_map_set_vaddr(&src, xrgb8888); > > drm_fb_xrgb8888_to_xrgb2101010(&dst, &result->dst_pitch, &src, &fb, ¶ms->clip); > - buf = le32buf_to_cpu(test, buf, TEST_BUF_SIZE); > + buf = le32buf_to_cpu(test, buf, dst_size / sizeof(u32)); > KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0); > } Thanks a lot for fixing this bug David, I just tested it and worked as expected. Do you think that we should update the other calls to le32buf_to_cpu() to follow a similar approach? Regardless of a possible follow up patch: Reviewed-by: José Expósito <jose.exposito89@xxxxxxxxx> Jose > > -- > 2.38.0.413.g74048e4d9e-goog >