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