Re: Possible build time regression affecting stable kernels

[Luiz Capitulino <luizcap@amazon.com>]

On 2023-06-01 11:45, Paul Moore wrote:

> 
> 
> 
> On Thu, Jun 1, 2023 at 11:03 AM Luiz Capitulino <luizcap@amazon.com> wrote:
>> On 2023-06-01 10:27, Paul Moore wrote:
>>> On Wed, May 31, 2023 at 10:13 PM Luiz Capitulino <luizcap@amazon.com> wrote:
>>>>
>>>> Hi Paul,
>>>>
>>>> A number of stable kernels recently backported this upstream commit:
>>>>
>>>> """
>>>> commit 4ce1f694eb5d8ca607fed8542d32a33b4f1217a5
>>>> Author: Paul Moore <paul@paul-moore.com>
>>>> Date:   Wed Apr 12 13:29:11 2023 -0400
>>>>
>>>>        selinux: ensure av_permissions.h is built when needed
>>>> """
>>>>
>>>> We're seeing a build issue with this commit where the "crash" tool will fail
>>>> to start, it complains that the vmlinux image and /proc/version don't match.
>>>>
>>>> A minimum reproducer would be having "make" version before 4.3 and building
>>>> the kernel with:
>>>>
>>>> $ make bzImages
>>>> $ make modules
>>>
>>> ...
>>>
>>>> This only happens with commit 4ce1f694eb5 applied and older "make", in my case I
>>>> have "make" version 3.82.
>>>>
>>>> If I revert 4ce1f694eb5 or use "make" version 4.3 I get identical strings (except
>>>> for the "Linux version" part):
>>>
>>> Thanks Luiz, this is a fun one :/
>>
>> It was a fun to debug TBH :-)
>>
>>> Based on a quick search, it looks like the grouped target may be the
>>> cause, especially for older (pre-4.3) versions of make.  Looking
>>> through the rest of the kernel I don't see any other grouped targets,
>>> and in fact the top level Makefile even mentions holding off on using
>>> grouped targets until make v4.3 is common/required.
>>
>> Exactly.
>>
>>> I don't have an older userspace immediately available, would you mind
>>> trying the fix/patch below to see if it resolves the problem on your
>>> system?  It's a cut-n-paste so the patch may not apply directly, but
>>> it basically just removes the '&' from the make rule, turning it into
>>> an old-fashioned non-grouped target.
>>
>> I tried the attached patch on top of latest Linus tree (ac2263b588dffd),
>> but unfortunately I got the same issue which is puzzling. Reverting
>> 4ce1f694eb5d8ca607fed8542d32a33b4f1217a5 does solve the issue though.
> 
> I'm at a bit of a loss here ... the only thing that seems to jump out
> is that the genheaders tool is run twice without the grouped target
> approach, but with both runs happening at the same point in the build
> and the second run updating both header files, I'm a bit at a loss as
> to why this would be problematic.
> 
> I don't want to block on fixing the kernel build while I keep chasing
> some esoteric build behavior so I'm just going to revert the patch
> with a note to revisit this when we require make >= 4.3.
> 
> Regardless, thanks for the report and the help testing, expect a
> patch/revert shortly ...

Thank you Paul, I really appreciate your fast response. I'd also
appreciate if you CC me in the revert patch so that I don't loose
track of it.

- Luiz