Re: [REGRESSION] Linux kernel 6.12.75 fails to compile with -Werror=implicit-function-declaration

[Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>]

Hi Peter,

On 06/03/26 03:36, Peter Schneider wrote:
> 
> The people who tacked their Tested-by on yesterday's 6.1.165, 6.6.128 
> and 6.12.75 RC2 did so after testing without the patch "x86/kexec: add a 
> sanity check on previous kernel's ima kexec buffer", because after my 
> initial report you dropped it, but in the final releases it was present 
> again (essentially invalidating the Tested-By), causing the same build 
> failure, but only on X86, and only with CONFIG_WERROR=Y.
> 


I think the kernel unconditionally adds 
-Werror=implicit-function-declaration whether we enable WERROR or not.

Notes:
------

$ grep "WERROR" .config
# CONFIG_WERROR is not set
# CONFIG_KVM_WERROR is not set
# CONFIG_DRM_AMDGPU_WERROR is not set
# CONFIG_DRM_I915_WERROR is not set
# CONFIG_DRM_XE_WERROR is not set
# CONFIG_DRM_WERROR is not set

$ make -j arch/x86/kernel/setup.o
   DESCEND bpf/resolve_btfids
   DESCEND objtool
   INSTALL libsubcmd_headers
   CALL    scripts/checksyscalls.sh
   INSTALL libsubcmd_headers
   CC      arch/x86/kernel/setup.o
arch/x86/kernel/setup.c: In function ‘ima_get_kexec_buffer’:
arch/x86/kernel/setup.c:380:15: error: implicit declaration of function 
‘ima_validate_range’ [-Werror=implicit-function-declaration]
   380 |         ret = ima_validate_range(ima_kexec_buffer_phys, 
ima_kexec_buffer_size);
       |               ^~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[4]: *** [scripts/Makefile.build:229: arch/x86/kernel/setup.o] Error 1
make[3]: *** [scripts/Makefile.build:466: arch/x86/kernel] Error 2
make[2]: *** [scripts/Makefile.build:466: arch/x86] Error 2
make[1]: *** [/home/opc/linux/Makefile:1954: .] Error 2
make: *** [Makefile:224: __sub-make] Error 2

$  make -n V=1 arch/x86/kernel/setup.o | grep -o 
"Werror=implicit-function-declaration"
Werror=implicit-function-declaration

this is likely because scripts/Makefile.extrawarn in line 13 has this 
and that is then included in Makefile.

Notes:

Patch 1: introducing a generic helper (stable CCed)
Patch 2: fixing a bug using that helper (stable CCed)

So while stable scripts picked up two these was no conflict because of 
not picking one and the build problem is not seen in few configs because 
the code is really gated by CONFIG_HAVE_IMA_KEXEC, and HAVE_IMA_KEXEC is 
selected by CONFIG_IMA, so the build problem seen on some configs is 
equivalent to having CONFIG_IMA or not.


> Now in todays three releases which fix this, you wrote in the release 
> announcements "Only upgrade if you've observed a build failure with 
> 6.1.165." / 6.6.128 / 6.12.75.
> 
> But this wording is, IMHO, inaccurate and inadquate, because people who 
> built yesterdays releases with CONFIG_WERROR=N will not have seen a 
> build failure, and if they now, because of your release announcement, DO 
> NOT upgrade to one of todays releases, they now have a kernel with an 
> incomplete patchset, i.e. with only the patch ""x86/kexec: add a sanity 
> check on previous kernel's ima kexec buffer" and not the three missing 
> prerequisite patches from Harshit's patch series which he said he will 
> properly backport later, and this could be built only by lucky 
> coincedence, and THIS is the combination of code nobody actually tested 
> which Brett talked about.
> 
> What does it do? Does is cause harm? I don't know. Do you know? Maybe 
> Harshit could tell us if it's a serious omission or if it's not 
> critical. This, IMHO, should have been avoided. The better wording in 
> the release announcements of today would have been: "All users on X86 
> must upgrade", so that nobody stays, unaware, on a kernel with that 
> incomplete patch set.

I think only people having CONFIG_IMA are affected by this patch, and 
whoever have that will run into build failure. (As missing function is a 
for-sure build failure).

A possible process improvement while tagging to stable ?
I should have really marked Patch2 as dependent on Patch1, (similar to 
what we have in stable, we do have stable-dep-of tag for prerequisites).
but we might not need, as, how it worked all this way then: we might be 
running different configs(allmodconfig, allnoconfig, randconfig etc.,.) 
like in this case few configs detected this build failure. But this 
might help if there is a functional dependency and not compile time.

Thanks,
Harshit