All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Luiz Capitulino <luizcap@amazon.com>
Cc: paul@paul-moore.com, sashal@kernel.org, stable@vger.kernel.org
Subject: Re: Possible build time regression affecting stable kernels
Date: Thu, 1 Jun 2023 14:20:32 +0100	[thread overview]
Message-ID: <2023060148-levers-freight-5b11@gregkh> (raw)
In-Reply-To: <20259cf7-d50d-4eca-482b-3a89cc94df7b@amazon.com>

On Thu, Jun 01, 2023 at 09:13:21AM -0400, Luiz Capitulino wrote:
> 
> 
> On 2023-06-01 02:06, Greg KH wrote:
> 
> > 
> > 
> > 
> > On Wed, May 31, 2023 at 10:12:40PM -0400, Luiz Capitulino 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
> > > 
> > > Then compare the version strings in the bzImage and vmlinux images,
> > > we can use "strings" for this. For example, in the 5.10.181 kernel I get:
> > > 
> > > $ strings vmlinux | egrep '^Linux version'
> > > Linux version 5.10.181 (ec2-user@ip-172-31-79-134.ec2.internal) (gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15), GNU ld version 2.29.1-31.amzn2) #2 SMP Thu Jun 1 01:26:38 UTC 2023
> > > 
> > > $ strings ./arch/x86_64/boot/bzImage | egrep 'ld version'
> > > 5.10.181 (ec2-user@ip-172-31-79-134.ec2.internal) (gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15), GNU ld version 2.29.1-31.amzn2) #1 SMP Thu Jun 1 01:23:59 UTC 2023
> > > 
> > > The version string in the bzImage doesn't have the "Linux version" part, but
> > > I think this is added by the kernel when printing. If you compare the strings,
> > > you'll see that they have a different build date and the "#1" and "#2" are
> > > different.
> > > 
> > > 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):
> > > 
> > > $ strings vmlinux | egrep '^Linux version'
> > > Linux version 5.10.181+ (ec2-user@ip-172-31-79-134.ec2.internal) (gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15), GNU ld version 2.29.1-31.amzn2) #1 SMP Thu Jun 1 01:29:11 UTC 2023
> > > 
> > > $ strings ./arch/x86_64/boot/bzImage | egrep 'ld version'
> > > 5.10.181+ (ec2-user@ip-172-31-79-134.ec2.internal) (gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15), GNU ld version 2.29.1-31.amzn2) #1 SMP Thu Jun 1 01:29:11 UTC 2023
> > > 
> > > Maybe the grouped target usage in 4ce1f694eb5 with older "make" is causing a
> > > rebuild of the vmlinux image in "make modules"? If yes, is this expected?
> > > 
> > > I'm afraid this issue could be high impact for distros with older user-space.
> > 
> > Is this issue also in 6.4-rc1 where this change came from?
> 
> Yes. I'm reporting this here because I'm more concerned with -stable kernels since
> they're more likely to be running on older user-space.

Yeah, we are bug-compatible!  :)

When this gets fixed in Linus's tree, I'll be glad to backport the
changes to the other kernels.  Please work with the developers to get
that fixed there.

thanks,

greg k-h

  reply	other threads:[~2023-06-01 13:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-01  2:12 Possible build time regression affecting stable kernels Luiz Capitulino
2023-06-01  6:06 ` Greg KH
2023-06-01 13:13   ` Luiz Capitulino
2023-06-01 13:20     ` Greg KH [this message]
2023-06-01 13:26       ` Luiz Capitulino
2023-06-01 14:13         ` Greg KH
2023-06-01 14:22           ` Luiz Capitulino
2023-06-01 14:56       ` Paul Moore
2023-06-01 15:51         ` Greg KH
2023-06-01 18:39           ` Paul Moore
2023-06-28 18:33             ` Greg KH
2023-06-28 23:33               ` Paul Moore
2023-06-29  8:43                 ` Greg KH
2023-06-29 15:55                   ` Paul Moore
2023-06-29 16:07                     ` Greg KH
2023-06-29 16:20                       ` Paul Moore
2023-06-01 14:27 ` Paul Moore
2023-06-01 15:02   ` Luiz Capitulino
2023-06-01 15:45     ` Paul Moore
2023-06-01 15:50       ` Luiz Capitulino
2023-06-01 17:05         ` Greg KH
2023-06-01 18:10           ` Paul Moore
2023-06-01 18:15             ` Luiz Capitulino
2023-06-01 18:41               ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2023060148-levers-freight-5b11@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=luizcap@amazon.com \
    --cc=paul@paul-moore.com \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.