-Wuninitialized-const-pointer in arch/arm64/kvm/sys_regs.c

[JustinStitt]

The cli only reports this failure for android14-6.1 (clang-22) which seems correct as this code area was reworked by kernel Commit 7af0c25 ("KVM: arm64: Normalize cache configuration").

$ make LLVM=1 ARCH=arm64 -j128 arch/arm64/kvm/sys_regs.o

../arch/arm64/kvm/sys_regs.c:2978:23: warning: variable 'clidr' is uninitialized when passed as a const pointer argument here [-Wuninitialized-const-pointer]
 2978 |         get_clidr_el1(NULL, &clidr); /* Ugly... */
      |                              ^~~~~
1 warning generated.

Patch: https://lore.kernel.org/lkml/20250724-b4-clidr-unint-const-ptr-v1-1-67c4d620b6b6@google.com

I've sent this only for v6.1.y aimed at stable as this patch cannot be upstreamed (this code has been reworked).

[JustinStitt]

@nathanchance What are the steps forward following the discussion on the mailing list?

[JustinStitt]

I see the two options as:

1. Try to backport Akihiko Odaki's tree from Commit e8789ab ("Merge branch kvm-arm64/virtual-cache-geometry into kvmarm/next") to 6.1 AND 5.15.

2. Patch arch/arm64/kvm/Makefile with CFLAGS_sys_regs.o += $(call cc-disable-warning,uninitialized-const-pointer)

[nathanchance]

I was thinking about that this weekend. I initially thought that we could explore backporting the series that Marc mentioned that reworks this code, as it appears relatively self contained and it gets rid of the construct altogether. However, since we are already going to need to disable the warning for the file in 5.15, I think we might as well just do the same thing in 6.1, so I think

diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index 989bb5dad2c8..173fc160165c 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -25,3 +25,5 @@ kvm-y := $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o \
         vgic/vgic-its.o vgic/vgic-debug.o

 kvm-$(CONFIG_HW_PERF_EVENTS)  += pmu-emul.o
+
+CFLAGS_sys_regs.o := $(call cc-disable-warning, uninitialized-const-pointer)

is the way forward. Shouldn't be that big of a deal IMO.

[nathanchance]

Lol of course you basically said the same thing and GitHub hadn't refreshed nor had I checked my email 😅

[JustinStitt]

However, since we are already going to need to disable the warning for the file in 5.15, I think we might as well just do the same thing in 6.1, so I think

Is the backport substantially more difficult for 5.15? is 5.15 missing some kvm plumbing that 6.1+ has?

[nathanchance]

Is the backport substantially more difficult for 5.15? is 5.15 missing some kvm plumbing that 6.1+ has?

Sounds like it based on Marc's response: https://lore.kernel.org/86bjp88b5s.wl-maz@kernel.org/

[JustinStitt]

I'll go ahead and send the new patch.

Should I send one for 6.1 and one for 5.15? Obviously no upstream patches either.

I sent two patches, one for 5.15, the other for 6.1

[PATCH 5.15.y] KVM: arm64: sys_regs: disable -Wuninitialized-const-pointer warning

[PATCH 6.1.y] KVM: arm64: sys_regs: disable -Wuninitialized-const-pointer warning

[nathanchance]

If the same patch applies to both 5.15 and 6.1 with patch -p1, you can use a subject prefix of 6.1 and 5.15 or something like that. If you include stable only in the commit message, Sasha's bot won't warn about not being able to find the commit upstream. No problem with sending two separate patches though, they will get processed in the same way.