clang-18 built kernel v6.11 leads to desktop graphics corruption + "AMDGPU(0): amdgpu_setup_kernel_mem failed" vs. same kernel built with gcc-14 runs ok (v6.11, x86_64)

[ernsteiswuerfel]

I reported the amdgpu graphics corruption issue at https://gitlab.freedesktop.org/drm/amd/-/issues/3638. I got the issue starting with kernel v6.10.10, so I bisected it to the following commit:

[...]
# first bad commit: [675d6d34fc1c36a7cee0d10e06985fb1e6bc7746] drm/amdgpu: always allocate cleared VRAM for GEM allocations

drm/amdgpu: always allocate cleared VRAM for GEM allocations
This adds allocation latency, but aligns better with user
expectations.  The latency should improve with the drm buddy
clearing patches that Arun has been working on.

In addition this fixes the high CPU spikes seen when doing
wipe on release.

v2: always set AMDGPU_GEM_CREATE_VRAM_CLEARED (Christian)

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3528
Fixes: a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
Acked-by: Arunpravin Paneer Selvam <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]> (v1)
Signed-off-by: Alex Deucher <[email protected]>
Cc: Arunpravin Paneer Selvam <[email protected]>
Cc: Christian König <[email protected]>
(cherry picked from commit 6c0a7c3c693ac84f8b50269a9088af8f37446863)
Cc: [email protected] # 6.10.x

Turns out this only happens when I build the kernel with clang-18 but not when I build it with gcc-14. Reverting the above commit 'fixes' the clang-18 built kernel too and I get no graphics corruption. Current mainline kernel v6.11 shows the same issue on my system.

clang and gcc kernel .config attached.
config_6110_zen3_gcc14.txt
config_6110_zen3_clang18.txt

[nathanchance]

None of the differences I see between the configurations would appear to cause this. There is not much information to go on here. It is entirely possible this is a code problem that just happens to show up with clang due to optimization or code generation differences. Testing with CONFIG_KMSAN, CONFIG_KCSAN, or CONFIG_UBSAN may help unearth some clues. Some input from the AMD developers would be helpful, hopefully they will continue to investigate it.

[ernsteiswuerfel]

No suspicious output with KASAN and/or UBSAN.

With KMSAN (no other sanitizers selected) the the kernel doesn't boot at all however. It gets stuck at UEFI bootscreen stating that it will load the kernel image, but after that nothing for several minutes...

[nathanchance]

Thanks for double checking on the sanitizers. Another thing to check is if this happens with an older or newer version of LLVM, which may point to a regression.

With KMSAN (no other sanitizers selected) the the kernel doesn't boot at all however. It gets stuck at UEFI bootscreen stating that it will load the kernel image, but after that nothing for several minutes...

cc @ramosian-glider, that sounds unexpected?

[ernsteiswuerfel]

I'll check with llvm 19.1.1 once it's out and report back (also on the KMSAN issue).

[ramosian-glider]

With KMSAN (no other sanitizers selected) the the kernel doesn't boot at all however. It gets stuck at UEFI bootscreen stating that it will load the kernel image, but after that nothing for several minutes...

Can you please share the kernel build config?

[ernsteiswuerfel]

@ramosian-glider Here's my v6.10.12 one. Same config without KMSAN boots just fine with my Ryzen 5950X.
config_61012_zen3.txt

[ernsteiswuerfel]

Did a build now with 19.1.1 and kernel v6.11.1 and can confirm the amdgpu graphics corruption is still there.

Also the kernel not booting with KMSAN enabled. Just opened #2054 on that one to avoid confusion.

[ernsteiswuerfel]

Found out the issue only shows up when CONFIG_INIT_STACK_ALL_PATTERN=y is enabled in the kernel .config. Same config with CONFIG_INIT_STACK_ALL_ZERO=y or CONFIG_INIT_STACK_NONE=y otherwise works just fine.

So the current situation is to either revert 675d6d3 or to not use
CONFIG_INIT_STACK_ALL_PATTERN=y when building with clang.

v6.11.2 kernel .config attached.
config_6112_zen3_van-.txt

[nickdesaulniers]

Perhaps the value assigned to flags itself was not initialized fully, resulting in corrupted bit patterns later?

[nathanchance]

I am surprised that GCC would not show the same problem. Maybe there is a subtle difference in the implementation of pattern initialization between clang and GCC? However, due to pattern initialization being the key trigger, I would say it is more likely that there is a bug in the kernel code (like undefined behavior) than the compiler (or maybe #2033 could be at play here, haven't looked at where flags comes from yet).

[ernsteiswuerfel]

[...] (or maybe #2033 could be at play here, haven't looked at where flags comes from yet).

Checked that out now (applying the patch from #2033 minus the tests on top of 19.1.1) and rebuilding the kernel with CONFIG_INIT_STACK_ALL_PATTERN=y but it didn't make a difference. Must be something else...

[nathanchance]

Does initializing info with = {} in amdgpu_gem_op_ioctl() help?

[ernsteiswuerfel]

Initializing info via info = {}; does not work so I used:

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -861,7 +861,7 @@ int amdgpu_gem_op_ioctl(struct drm_device *dev, void *data,
 
        switch (args->op) {
        case AMDGPU_GEM_OP_GET_GEM_CREATE_INFO: {
-               struct drm_amdgpu_gem_create_in info;
+               struct drm_amdgpu_gem_create_in info = {0};
                void __user *out = u64_to_user_ptr(args->value);
 
                info.bo_size = robj->tbo.base.size;

But it didn't not help with the issue, corruption still there.

[ernsteiswuerfel]

Another user is experiencing a similar issue https://gitlab.freedesktop.org/drm/amd/-/issues/3660.

He also states this problem with CONFIG_INIT_STACK_ALL_PATTERN=y in his case with clang-14.