On Thu, Jun 1, 2023 at 11:03 AM Luiz Capitulino <luizcap@xxxxxxxxxx> wrote: > On 2023-06-01 10:27, Paul Moore wrote: > > On Wed, May 31, 2023 at 10:13 PM Luiz Capitulino <luizcap@xxxxxxxxxx> wrote: > >> > >> Hi Paul, > >> > >> A number of stable kernels recently backported this upstream commit: > >> > >> """ > >> commit 4ce1f694eb5d8ca607fed8542d32a33b4f1217a5 > >> Author: Paul Moore <paul@xxxxxxxxxxxxxx> > >> 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 ... -- paul-moore.com
