On 2023-06-01 11:45, Paul Moore wrote:
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 ...
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
