Problems building RT stable for v6.1.175

Sasha,

I was having some compilation problems building the v6.1-rt branch after merging v6.1.175. I'm building on an up-to-date Fedora 44, using gcc 16.1.1.

------------------------
First I saw this:

CC [M] arch/x86/kvm/vmx/vmx.o
In file included from /lilnas/src/stable-rt/v6.1-rt/arch/x86/kvm/vmx/vmx.h:15,

                 from /lilnas/src/stable-rt/v6.1-rt/arch/x86/kvm/vmx/nested.h:7,
                 from /lilnas/src/stable-rt/v6.1-rt/arch/x86/kvm/vmx/vmx.c:63:
/lilnas/src/stable-rt/v6.1-rt/arch/x86/kvm/vmx/vmx_ops.h:15:58: error: ‘regparm’ attribute ignored [-Werror=attributes]
   15 |                                                          bool fault);
      |                                                          ^~~~

cc1: all warnings being treated as errors
make[4]: *** [/lilnas/src/stable-rt/v6.1-rt/scripts/Makefile.build:250: arch/x86/kvm/vmx/vmx.o] Error 1 make[3]: *** [/lilnas/src/stable-rt/v6.1-rt/scripts/Makefile.build:503: arch/x86/kvm] Error 2 make[2]: *** [/lilnas/src/stable-rt/v6.1-rt/scripts/Makefile.build:503: arch/x86] Error 2 make[1]: *** [/lilnas/src/stable-rt/v6.1-rt/Makefile:2025: .] Error 2
make: *** [Makefile:238: __sub-make] Error 2

The fix there is to add const to the definition of next_path:

index 7bd6aff6e260..33b214a91338 100644
@@ -10748,7 +10748,7 @@ static int resolve_full_path(const char *file, char *result, size_t result_sz)
                if (!search_paths[i])
                        continue;
                for (s = search_paths[i]; s != NULL; s = strchr(s, ':')) {
-                       char *next_path;
+                       const char *next_path;
                        int seg_len;
 
                        if (s[0] == ':')

------------------------
next up is a warning-as-failure in libbpf.c:

CC [M] arch/x86/kvm/vmx/vmx.o
In file included from /lilnas/src/stable-rt/v6.1-rt/arch/x86/kvm/vmx/vmx.h:15,
from /lilnas/src/stable-rt/v6.1-rt/arch/x86/kvm/vmx/nested.h:7,
from /lilnas/src/stable-rt/v6.1-rt/arch/x86/kvm/vmx/vmx.c:63:
/lilnas/src/stable-rt/v6.1-rt/arch/x86/kvm/vmx/vmx_ops.h:15:58: error: ‘regparm’ attribute ignored [-Werror=attributes]

   15 |                                                          bool fault);
      |                                                          ^~~~

cc1: all warnings being treated as errors
make[4]: *** [/lilnas/src/stable-rt/v6.1-rt/scripts/Makefile.build:250: arch/x86/kvm/vmx/vmx.o] Error 1 make[3]: *** [/lilnas/src/stable-rt/v6.1-rt/scripts/Makefile.build:503: arch/x86/kvm] Error 2 make[2]: *** [/lilnas/src/stable-rt/v6.1-rt/scripts/Makefile.build:503: arch/x86] Error 2 make[1]: *** [/lilnas/src/stable-rt/v6.1-rt/Makefile:2025: .] Error 2
make: *** [Makefile:238: __sub-make] Error 2

I'll admit I had to ask my buddy Claude about this one. Turns out that the regparm attribute is relevant only on x86-32 and is meaningless on x86-64, so treated as a warning and a failure. The fix is to wrap the definition in an #ifdef for CONFIG_X86_32:

index 5edab28dfb2e..50328be40b2b 100644
@@ -11,8 +11,11 @@
 #include "../x86.h"
 
 void vmread_error(unsigned long field, bool fault);
-__attribute__((regparm(0))) void vmread_error_trampoline(unsigned long field,
-                                                        bool fault);
+/* regparm(0) overrides -mregparm=3 so args are stack-passed, matching asm callers */
+#ifdef CONFIG_X86_32
+__attribute__((regparm(0)))
+#endif
+void vmread_error_trampoline(unsigned long field, bool fault);
 void vmwrite_error(unsigned long field, unsigned long value);
 void vmclear_error(struct vmcs *vmcs, u64 phys_addr);
 void vmptrld_error(struct vmcs *vmcs, u64 phys_addr);

------------------------

Pretty sure you'll need these (or something equivalent) on 6.1 stable, when more people start using gcc 16.

Don't know if this email is enough but if you want I'll send you a patch series.

Regards,
Clark

The United States Coast Guard
Ruining Natural Selection since 1790

As you have found, gcc16 doesn't build this older kernel just yet. There are lots of patches that would need to be backported. If you wish to see this supported, please do so!

thanks,

greg k-h