Re: Possible build time regression affecting stable kernels

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Jun 01, 2023 at 11:50:16AM -0400, Luiz Capitulino wrote:
> 
> 
> 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.

And please add a cc: stable@ to it too :)