[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNAQkKOheXLVq+sjjmBMzREBZYN8XkxzcVmkkVpN4OjjRGQ@mail.gmail.com>
Date: Tue, 11 Feb 2020 05:13:39 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Michal Simek <monstr@...str.eu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Michal Marek <michal.lkml@...kovi.net>
Subject: Re: [PATCH v1] kbuild: Fix off-by-one error when generate a new version
Hi Andy,
On Mon, Jan 27, 2020 at 7:05 PM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> On Fri, Jan 24, 2020 at 09:58:59PM +0200, Andy Shevchenko wrote:
> > When build on, for example, x86 using `make O=... -j64` the version
> > in the built kernel comes from include/generated/compile.h, which is:
> >
> > #define UTS_VERSION "#351 SMP Fri Jan 24 18:46:34 EET 2020"
> >
> > While at the end the x86 specific Makefile prints the contents of
> > the .version file:
> >
> > Kernel: arch/x86/boot/bzImage is ready (#352)
> >
> > Obviously the latter is not true. This happens because we first
> > check compile.h and update it and then generate new version, which is
> > incorrect flow:
> >
> > CHK include/generated/compile.h
> > UPD include/generated/compile.h
> > ...
> > GEN .version
> >
> > In order to fix this, move the version generation from link-vmlinux.sh
> > to scripts/version.sh and re-use it in init/Makefile.
> >
> > Additionally provide a unified way to get the current version of the build
> > and use this in few callers. This will respect the KBUILD_BUILD_VERSION
> > in case it's provided.
>
> Hmm... It looks like a mess in my build tree.
> I have to setup more experiments here.
>
Sorry for the late reply.
I remember I was also hit by this one month ago or so.
I did not dig into it at that time
because the problem disappeared after doing something.
Today, I took a look at this again.
This is a regression caused by 56d589361572
This patch should fix it:
https://patchwork.kernel.org/patch/11374047/
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists