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

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

[Aditya Garg]

Hi

I found out that Linux kernel 6.12.75 failed to compiled in my automatic builds. The compiler throws the error:

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[7]: *** [scripts/Makefile.build:229: arch/x86/kernel/setup.o] Error 1
make[6]: *** [scripts/Makefile.build:466: arch/x86/kernel] Error 2
make[5]: *** [scripts/Makefile.build:466: arch/x86] Error 2

Upon searching a bit, I found out that failure of this patch to be backported seems to be main reason:

https://lore.kernel.org/all/20251231061609.907170-2-harshit.m.mogalapalli@oracle.com/

Looks like this series itself was not properly backported.

I am not sure if any other kernel version is affected. I currently build 6.19 and 6.12 series for my use.

Thanks!
Aditya

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

[Aditya Garg]

Looks like kernel 6.12, 6.6 and 6.1 series got only one part of the three patches sent, thus causing this regression.

Marking this as SEVERE, please forgive me if I did wrong.

> On 4 Mar 2026, at 11:05 PM, Aditya Garg <gargaditya08@live.com> wrote:
> 
> Hi
> 
> I found out that Linux kernel 6.12.75 failed to compiled in my automatic builds. The compiler throws the error:
> 
> 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[7]: *** [scripts/Makefile.build:229: arch/x86/kernel/setup.o] Error 1
> make[6]: *** [scripts/Makefile.build:466: arch/x86/kernel] Error 2
> make[5]: *** [scripts/Makefile.build:466: arch/x86] Error 2
> 
> Upon searching a bit, I found out that failure of this patch to be backported seems to be main reason:
> 
> https://lore.kernel.org/all/20251231061609.907170-2-harshit.m.mogalapalli@oracle.com/
> 
> Looks like this series itself was not properly backported.
> 
> I am not sure if any other kernel version is affected. I currently build 6.19 and 6.12 series for my use.
> 
> Thanks!
> Aditya

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

[Aditya Garg]

The faulty commit seems to be f8f73bf0f8a57ee9b86792456bd42079bc98c6b7 on 6.12

> On 4 Mar 2026, at 11:22 PM, Aditya Garg <gargaditya08@live.com> wrote:
> 
> Looks like kernel 6.12, 6.6 and 6.1 series got only one part of the three patches sent, thus causing this regression.
> 
> Marking this as SEVERE, please forgive me if I did wrong.
> 
>> On 4 Mar 2026, at 11:05 PM, Aditya Garg <gargaditya08@live.com> wrote:
>> 
>> Hi
>> 
>> I found out that Linux kernel 6.12.75 failed to compiled in my automatic builds. The compiler throws the error:
>> 
>> 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[7]: *** [scripts/Makefile.build:229: arch/x86/kernel/setup.o] Error 1
>> make[6]: *** [scripts/Makefile.build:466: arch/x86/kernel] Error 2
>> make[5]: *** [scripts/Makefile.build:466: arch/x86] Error 2
>> 
>> Upon searching a bit, I found out that failure of this patch to be backported seems to be main reason:
>> 
>> https://lore.kernel.org/all/20251231061609.907170-2-harshit.m.mogalapalli@oracle.com/
>> 
>> Looks like this series itself was not properly backported.
>> 
>> I am not sure if any other kernel version is affected. I currently build 6.19 and 6.12 series for my use.
>> 
>> Thanks!
>> Aditya

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

[Peter Schneider]

Am 04.03.2026 um 18:35 schrieb Aditya Garg:
> Hi
> 
> I found out that Linux kernel 6.12.75 failed to compiled in my automatic builds. The compiler throws the error:
> 
> 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[7]: *** [scripts/Makefile.build:229: arch/x86/kernel/setup.o] Error 1
> make[6]: *** [scripts/Makefile.build:466: arch/x86/kernel] Error 2
> make[5]: *** [scripts/Makefile.build:466: arch/x86] Error 2

I already found and reported this in the RC cycle [1], and Sasha dropped it in -rc2 [2], and now in the release, it 
obviously has, somewhat mysteriously, reappeared [3], affecting all of today's 6.x stable branch releases.


[1] https://lore.kernel.org/stable/66461c13-1bb3-473c-b57f-adba9db4f756@googlemail.com/
[2] https://lore.kernel.org/stable/a04b1aa6-ba46-4368-9dfe-6320a2dafa79@googlemail.com/
[3] https://lore.kernel.org/stable/c435a3c6-5952-453f-9e50-31e0c6cdd09f@googlemail.com/


Beste Grüße,
Peter Schneider

-- 
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you.                    -- David McCullough Jr.

OpenPGP:  0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244
Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@googlemail.com
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@gmail.com

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

[Peter Schneider]

Am 04.03.2026 um 20:00 schrieb Peter Schneider:
> Am 04.03.2026 um 18:35 schrieb Aditya Garg:
>> Hi
>>
>> I found out that Linux kernel 6.12.75 failed to compiled in my automatic builds. The compiler throws the error:
>>
>> 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[7]: *** [scripts/Makefile.build:229: arch/x86/kernel/setup.o] Error 1
>> make[6]: *** [scripts/Makefile.build:466: arch/x86/kernel] Error 2
>> make[5]: *** [scripts/Makefile.build:466: arch/x86] Error 2
> 
> I already found and reported this in the RC cycle [1], and Sasha dropped it in -rc2 [2], and now in the release, it 
> obviously has, somewhat mysteriously, reappeared [3], affecting all of today's 6.x stable branch releases.
> 
> 
> [1] https://lore.kernel.org/stable/66461c13-1bb3-473c-b57f-adba9db4f756@googlemail.com/
> [2] https://lore.kernel.org/stable/a04b1aa6-ba46-4368-9dfe-6320a2dafa79@googlemail.com/
> [3] https://lore.kernel.org/stable/c435a3c6-5952-453f-9e50-31e0c6cdd09f@googlemail.com/


I have to correct myself: the last two I screwed up myself by doing stupid things in the wrong directory 🙁

Sorry for the noise!

So 6.18.16 and 6.19.6 are fine, only 6.1.165, 6.6.128 and 6.12.75 are still affected.


Beste Grüße,
Peter Schneider

-- 
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you.                    -- David McCullough Jr.

OpenPGP:  0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244
Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@googlemail.com
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@gmail.com

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

[Brett A C Sheffield]

On 2026-03-04 20:00, Peter Schneider wrote:
> I already found and reported this in the RC cycle [1], and Sasha dropped it in -rc2 [2], and now in the release, it 
> obviously has, somewhat mysteriously, reappeared [3], affecting all of today's 6.x stable branch releases.

Greg, Sasha et al.

Can we make a small adjustment to the stable kernel testing process please,
whereby we release a kernel that we have actually tested, instead of adding and
dropping patches at the last moment and releasing a kernel that no one has
tested?

We are only a small pool of testers. If we find a bug, can we fix it, release a
new RC and test again please?  We can have an RC3. Even an RC4.  Perhaps if we
bogoselect fewer patches in the first place we might have less work to do. It's
better to miss a backport for a bug no one has reported than to pull stuff in
without proper review.

The current stable process is introducing bugs. Bugs that never existed in
mainline.

The 3 kernels released today were tested by no one before release. The seven
kernels yesterday were similarly tested by no one before release.  We weren't
given the opportunity.

There aren't enough of us to do this right, but we can do it less wrong with a
bit of caution.

Cheers,


Brett

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

[Sasha Levin]

On Thu, Mar 05, 2026 at 05:40:09PM +0000, Brett A C Sheffield wrote:
>On 2026-03-04 20:00, Peter Schneider wrote:
>> I already found and reported this in the RC cycle [1], and Sasha dropped it in -rc2 [2], and now in the release, it
>> obviously has, somewhat mysteriously, reappeared [3], affecting all of today's 6.x stable branch releases.
>
>Greg, Sasha et al.
>
>Can we make a small adjustment to the stable kernel testing process please,
>whereby we release a kernel that we have actually tested, instead of adding and
>dropping patches at the last moment and releasing a kernel that no one has
>tested?
>
>We are only a small pool of testers. If we find a bug, can we fix it, release a
>new RC and test again please?  We can have an RC3. Even an RC4.  Perhaps if we
>bogoselect fewer patches in the first place we might have less work to do. It's
>better to miss a backport for a bug no one has reported than to pull stuff in
>without proper review.

Could you suggest which fixes from v6.19..v6.19.6 could have been left outside
the tree?

>The current stable process is introducing bugs. Bugs that never existed in
>mainline.

Releasing yesterday's tree was (my) human error: I don't have as much
automation and scripting as Greg does, so many of the steps I've taken were
manual and prone to errors. I'm working on improving this workflow on my end.

This, however, wasn't an issue with our process, which is why I'm curious which
bugs you're referring to?

>The 3 kernels released today were tested by no one before release.

Right - the 3 kernels released today simply dropped a commit that caused a
built failure. We sometimes do that to address simple build or functionality
breakages (this happened with v6.19.2 and v6.19.5 too).

I don't disagree that there's a risk in doing so, but the risk is fairly minor,
and doing a quick release allows users to get important fixes without waiting
another cycle.

We could discuss a policy change here, but could you show that doing these
quick releases introduced regressions?

If not, why are we changing something that works?

>The seven kernels yesterday were similarly tested by no one before release.
>We weren't given the opportunity.

Could you explain this point please? There were quite a few folks who provided
their Tested-by...

-- 
Thanks,
Sasha

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

[Brett A C Sheffield]

On 2026-03-05 15:21, Sasha Levin wrote:
> On Thu, Mar 05, 2026 at 05:40:09PM +0000, Brett A C Sheffield wrote:

> >The current stable process is introducing bugs. Bugs that never existed in
> >mainline.
> 
> Releasing yesterday's tree was (my) human error: I don't have as much
> automation and scripting as Greg does, so many of the steps I've taken were
> manual and prone to errors. I'm working on improving this workflow on my end.

This raises two questions:

1) why do you not have the same tools? This whole process is highly automated,
both at your end, and ours. Little changes break scripts and cause much hassle
that could be avoided.  I had to debug my scripts before I could even get
started (my fault, my bug) because of a difference in how you sent the emails.
Others had similar problems by the sound of it.  Please, Greg, make these tools
and the process public and make sure whoever is cutting the release knows how to
use them.

2) why is so much scripting involved in cutting the final release? This should be
the exact kernel we just tested with our Tested-by lines and your signoff tacked
on.  Last minute changes break things.

> This, however, wasn't an issue with our process, which is why I'm curious which
> bugs you're referring to?
> 
> >The 3 kernels released today were tested by no one before release.
> 
> Right - the 3 kernels released today simply dropped a commit that caused a
> built failure. We sometimes do that to address simple build or functionality
> breakages (this happened with v6.19.2 and v6.19.5 too).
> 
> I don't disagree that there's a risk in doing so, but the risk is fairly minor,
> and doing a quick release allows users to get important fixes without waiting
> another cycle.
> 
> We could discuss a policy change here, but could you show that doing these
> quick releases introduced regressions?
> 
> If not, why are we changing something that works?

It isn't working, as we've just demonstrated.

It's not your fault, Sasha. It's a failure (lack) of process. You were trying to
release seven kernels, for the first time, without using the same tools as
usual.

The problem was that you (following the broken process), released kernels,
after modifying them, without getting anyone to retest.

In the rest of the software world testing happens after changes and before
release, not in the middle.

That's (mainly) what I want to change. No more last minute dropped and added
patches.

Tagging RCs would help at our end too, rather than relying on extracting
metadata from email headers, and trying to figure out which force-pushed commit
matches RCn at any given point in time.

> >The seven kernels yesterday were similarly tested by no one before release.
> >We weren't given the opportunity.
> 
> Could you explain this point please? There were quite a few folks who provided
> their Tested-by...

Yes, I was one of them, although you omitted mine from the hastily pushed 6.6
and 6.12 kernels ;-)

Taking 6.6 as an example because I have the numbers on the whiteboard beside me:

RC1 had 375 patches.
RC2 had 956.
These are not the same kernel.

Then we had another RC2 force-pushed over the top of the original RC2 confusing
the hell out of me after two long kernel bisects when I found my tree was out of
sync and wasting a bunch more time as I retested because I thought I must have
made a mistake.

So for 6.6 and 6.12 I tested 3 kernels each, none of which were what was actually
released.

And that turned out to be broken. Which we could have told you, if we'd had an
RC to test.

The re-testing happened anyway, after release. I re-tested 6.6 and 6.12 and they
seemed fine. Peter retested and found it was broken. Better for that to have
been an RC3. Less work for you cutting extra releases, and less public
embarrassment for an already tarnished stable kernel process.

This whole release cycle was a complete mess, not because of one person, but
because of poor process and missing tools.


Brett

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

[Sasha Levin]

On Thu, Mar 05, 2026 at 10:57:49PM +0100, Brett A C Sheffield wrote:
>On 2026-03-05 15:21, Sasha Levin wrote:
>> On Thu, Mar 05, 2026 at 05:40:09PM +0000, Brett A C Sheffield wrote:
>
>> >The current stable process is introducing bugs. Bugs that never existed in
>> >mainline.
>>
>> Releasing yesterday's tree was (my) human error: I don't have as much
>> automation and scripting as Greg does, so many of the steps I've taken were
>> manual and prone to errors. I'm working on improving this workflow on my end.
>
>This raises two questions:
>
>1) why do you not have the same tools? This whole process is highly automated,
>both at your end, and ours. Little changes break scripts and cause much hassle
>that could be avoided.  I had to debug my scripts before I could even get
>started (my fault, my bug) because of a difference in how you sent the emails.
>Others had similar problems by the sound of it.  Please, Greg, make these tools
>and the process public and make sure whoever is cutting the release knows how to
>use them.

Greg's scripts are public :)

We have very different development environments. We use different tools, our
workflows are different, and we (normally) handle different parts of the
process. Sure, at times it creates issues (like here, when I'm trying to tackle
some of Greg's work), but sometimes it also helps us catch issues that one of
us would have missed. The latter part usually happens behind the scenes when no
one notices.

I suppose that if I were to do releases more often we'd likely end up with the
same (or similar) set of scripts around this. We're not there.

>2) why is so much scripting involved in cutting the final release? This should be
>the exact kernel we just tested with our Tested-by lines and your signoff tacked
>on.  Last minute changes break things.

The stable kernel is managed by a quilt set of branches in the background.
Every release of the stable tree (for forever?) has been generated that day
from the quilt queue and released. There is no notion of "exact kernel" because
the tree, until it's released, is ephermal.

What happened in this case, is that I dropped the offending commit from the
quilt queue and regenerated the trees, and pushed out -rc2. I'm still trying to
learn why the change to the quilt queue wasn't pushed out, but when the trees
were later regenrated from the queue, it still had the offending commit.

There was no irresponsible last second change as you're trying to suggest.

>> This, however, wasn't an issue with our process, which is why I'm curious which
>> bugs you're referring to?
>>
>> >The 3 kernels released today were tested by no one before release.
>>
>> Right - the 3 kernels released today simply dropped a commit that caused a
>> built failure. We sometimes do that to address simple build or functionality
>> breakages (this happened with v6.19.2 and v6.19.5 too).
>>
>> I don't disagree that there's a risk in doing so, but the risk is fairly minor,
>> and doing a quick release allows users to get important fixes without waiting
>> another cycle.
>>
>> We could discuss a policy change here, but could you show that doing these
>> quick releases introduced regressions?
>>
>> If not, why are we changing something that works?
>
>It isn't working, as we've just demonstrated.

So this is narrowly about the 3 releases from earlier today, where there were
concerns that these small releases without -rcs prior are causing regressions.
I'm trying to understand which regressions were caused by this type of
releases.

>It's not your fault, Sasha. It's a failure (lack) of process. You were trying to
>release seven kernels, for the first time, without using the same tools as
>usual.
>
>The problem was that you (following the broken process), released kernels,
>after modifying them, without getting anyone to retest.
>
>In the rest of the software world testing happens after changes and before
>release, not in the middle.
>
>That's (mainly) what I want to change. No more last minute dropped and added
>patches.
>
>Tagging RCs would help at our end too, rather than relying on extracting
>metadata from email headers, and trying to figure out which force-pushed commit
>matches RCn at any given point in time.
>
>> >The seven kernels yesterday were similarly tested by no one before release.
>> >We weren't given the opportunity.
>>
>> Could you explain this point please? There were quite a few folks who provided
>> their Tested-by...
>
>Yes, I was one of them, although you omitted mine from the hastily pushed 6.6
>and 6.12 kernels ;-)
>
>Taking 6.6 as an example because I have the numbers on the whiteboard beside me:
>
>RC1 had 375 patches.
>RC2 had 956.
>These are not the same kernel.

It's not :)

This one was a fun git bug to figure out.

-rc2, however, had the same amount of time to be tested, and the test priod for
-rc2 was Monday-Wednesday rather than the weeked for -rc1.

-rc1 was in no place to be released as is, so what would have been my other
choice? I can't release a tree with two thirds of it's commits missing, so I go
ahead and do an -rc2 with more commits, and I allow time for testing.

>Then we had another RC2 force-pushed over the top of the original RC2 confusing
>the hell out of me after two long kernel bisects when I found my tree was out of
>sync and wasting a bunch more time as I retested because I thought I must have
>made a mistake.

This is on me. I decided to push -rc2 because the issue was pointed out so
quickly I felt I could sneak it in.

-- 
Thanks,
Sasha

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

[Peter Schneider]

Am 05.03.2026 um 21:21 schrieb Sasha Levin:
> On Thu, Mar 05, 2026 at 05:40:09PM +0000, Brett A C Sheffield wrote:
>> On 2026-03-04 20:00, Peter Schneider wrote:
>>> I already found and reported this in the RC cycle [1], and Sasha dropped it in -rc2 [2], and now in the release, it
>>> obviously has, somewhat mysteriously, reappeared [3], affecting all of today's 6.x stable branch releases.
>>
>> Greg, Sasha et al.
>>
>> Can we make a small adjustment to the stable kernel testing process please,
>> whereby we release a kernel that we have actually tested, instead of adding and
>> dropping patches at the last moment and releasing a kernel that no one has
>> tested?
>>
>> We are only a small pool of testers. If we find a bug, can we fix it, release a
>> new RC and test again please?  We can have an RC3. Even an RC4.  Perhaps if we
>> bogoselect fewer patches in the first place we might have less work to do. It's
>> better to miss a backport for a bug no one has reported than to pull stuff in
>> without proper review.
> 
> Could you suggest which fixes from v6.19..v6.19.6 could have been left outside
> the tree?
> 
>> The current stable process is introducing bugs. Bugs that never existed in
>> mainline.
> 
> Releasing yesterday's tree was (my) human error: I don't have as much
> automation and scripting as Greg does, so many of the steps I've taken were
> manual and prone to errors. I'm working on improving this workflow on my end.
> 
> This, however, wasn't an issue with our process, which is why I'm curious which
> bugs you're referring to?
> 
>> The 3 kernels released today were tested by no one before release.
> 
> Right - the 3 kernels released today simply dropped a commit that caused a
> built failure. We sometimes do that to address simple build or functionality
> breakages (this happened with v6.19.2 and v6.19.5 too).

I agree with that, and in this case I don't see a risk here. It's probably fine.

But I have a major headache regarding this one, because Brett is right here:

>> The seven kernels yesterday were similarly tested by no one before release.
>> We weren't given the opportunity.
> 
> Could you explain this point please? There were quite a few folks who provided
> their Tested-by...

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.

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.

This gives me some vibes of "It compiles, so let's ship it", which is a questionable level of QA you might expect from 
some (shady) commercial companies, but I think the Linux community should (and can!) do better. But I feel the process 
was kinda broken this time, not because of your fault, but because lack of consistency in tooling, as you said yourself. 
And also the unlucky timing of finding that bash/dash behaviour differnence in your tooling vs Greg's, that caused RC2 
in the first place.

Sorry if that sounds too harsh. I don't mean it in a harsh way, but only as constructive criticism. I know Greg and you 
have an extremely complex job with maintaining the stable branches, and normally all works very well and smooth, because 
both of you are doing a hell of an excellent job! But on occasion when a release was bumpy like this one, we should look 
back and ask why, and what could have done better, and how we can improve in the future.


Beste Grüße,
Peter Schneider

-- 
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you.                    -- David McCullough Jr.

OpenPGP:  0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244
Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@googlemail.com
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@gmail.com

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

[Harshit Mogalapalli]

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

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

[Peter Schneider]

Hi Harshit,

Am 05.03.2026 um 23:46 schrieb Harshit Mogalapalli:

> Hi Peter,
> 
> On 06/03/26 03:36, Peter Schneider wrote:

[...]

>> 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).

Thanks very much for your detailed explanation, you have relieved my worries and headache!

Beste Grüße,
Peter Schneider

-- 
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you.                    -- David McCullough Jr.

OpenPGP:  0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244
Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@googlemail.com
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@gmail.com

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

[Sasha Levin]

On Thu, Mar 05, 2026 at 11:06:06PM +0100, Peter Schneider wrote:
>This gives me some vibes of "It compiles, so let's ship it", which is 
>a questionable level of QA you might expect from some (shady) 
>commercial companies, but I think the Linux community should (and 
>can!) do better.

I really want to highlight this part.

There are no IMA tests I'm aware of (outside of builds with CONFIG_IMA=y).

For that matter, we only see a minority of subsystems actually testing stable
releases.

This is something we've been working to improve for a while, but we're quite
far from that goal.

Sadly your vibes are somewhat grounded in reality.

>Sorry if that sounds too harsh. I don't mean it in a harsh way, but 
>only as constructive criticism. I know Greg and you have an extremely 
>complex job with maintaining the stable branches, and normally all 
>works very well and smooth, because both of you are doing a hell of an 
>excellent job! But on occasion when a release was bumpy like this one, 
>we should look back and ask why, and what could have done better, and 
>how we can improve in the future.

This is not, and I appreciate the feedback. Thank you.

-- 
Thanks,
Sasha