kernel/linux-kernel-base: Fix kernel build artefact determinism issues

With the 6.1 kernel we've seen reproducibility/determinism issues where the kernel
seems to rebuild headers referencing the hostname or local user. kernel-devsrc
building after the kernel seemed to trigger it in some cases.

Moving the definitions to the bbclass used by all the kernel recipe code including
kernel-devsrc seems to be the best way to ensure this doesn't happen.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 meta/classes-recipe/kernel.bbclass            | 3 ---
 meta/classes-recipe/linux-kernel-base.bbclass | 4 ++++
 2 files changed, 4 insertions(+), 3 deletions(-)

On Thu, Jan 26, 2023 at 5:10 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> With the 6.1 kernel we've seen reproducibility/determinism issues where the kernel
> seems to rebuild headers referencing the hostname or local user. kernel-devsrc
> building after the kernel seemed to trigger it in some cases.
>
> Moving the definitions to the bbclass used by all the kernel recipe code including
> kernel-devsrc seems to be the best way to ensure this doesn't happen.
>

This is the right thing to do.

I haven't been able to root cause how the 6.1 kernel file generation was
being triggered by devsrc, and how it raced with the main kernel to change
the build-artifacts .. but it most definitely did do it.

At the very least, this rules out a lot of paths to the generation  of the
header files, and if it happens again, it will be easier to track down.

Bruce

> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  meta/classes-recipe/kernel.bbclass            | 3 ---
>  meta/classes-recipe/linux-kernel-base.bbclass | 4 ++++
>  2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/meta/classes-recipe/kernel.bbclass b/meta/classes-recipe/kernel.bbclass
> index bd3b6471c6b..4fbe84c4e42 100644
> --- a/meta/classes-recipe/kernel.bbclass
> +++ b/meta/classes-recipe/kernel.bbclass
> @@ -210,9 +210,6 @@ PACKAGES_DYNAMIC += "^${KERNEL_PACKAGE_NAME}-firmware-.*"
>
>  export OS = "${TARGET_OS}"
>  export CROSS_COMPILE = "${TARGET_PREFIX}"
> -export KBUILD_BUILD_VERSION = "1"
> -export KBUILD_BUILD_USER ?= "oe-user"
> -export KBUILD_BUILD_HOST ?= "oe-host"
>
>  KERNEL_RELEASE ?= "${KERNEL_VERSION}"
>
> diff --git a/meta/classes-recipe/linux-kernel-base.bbclass b/meta/classes-recipe/linux-kernel-base.bbclass
> index cb2212c9485..65cc48f304d 100644
> --- a/meta/classes-recipe/linux-kernel-base.bbclass
> +++ b/meta/classes-recipe/linux-kernel-base.bbclass
> @@ -43,5 +43,9 @@ def linux_module_packages(s, d):
>      suffix = ""
>      return " ".join(map(lambda s: "kernel-module-%s%s" % (s.lower().replace('_', '-').replace('@', '+'), suffix), s.split()))
>
> +export KBUILD_BUILD_VERSION = "1"
> +export KBUILD_BUILD_USER ?= "oe-user"
> +export KBUILD_BUILD_HOST ?= "oe-host"
> +
>  # that's all
>
> --
> 2.37.2
>

On Thu, 2023-01-26 at 17:14 -0500, Bruce Ashfield wrote:
> On Thu, Jan 26, 2023 at 5:10 PM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > 
> > With the 6.1 kernel we've seen reproducibility/determinism issues where the kernel
> > seems to rebuild headers referencing the hostname or local user. kernel-devsrc
> > building after the kernel seemed to trigger it in some cases.
> > 
> > Moving the definitions to the bbclass used by all the kernel recipe code including
> > kernel-devsrc seems to be the best way to ensure this doesn't happen.
> > 
> 
> This is the right thing to do.
> 
> I haven't been able to root cause how the 6.1 kernel file generation was
> being triggered by devsrc, and how it raced with the main kernel to change
> the build-artifacts .. but it most definitely did do it.
> 
> At the very least, this rules out a lot of paths to the generation  of the
> header files, and if it happens again, it will be easier to track down.

Sadly this didn't work and wasn't enough. The reason the test builds
worked is that both the A and B builds being compared ran on the same
host. On the release build one came from sstate, one built locally and
game over again, the hostnames were different.

First, I needed to reproduce this locally. I could do that with:

bitbake virtual/kernel perf kernel-devsrc -c clean
bitbake virtual/kernel -c compile -f
bitbake kernel-devsrc

cat tmp/work-shared/qemux86-64/kernel-build-artifacts/include/generated/compile.h

and noting that it contains my hostname, not "oe-host".

With a reproducer, I was then able to work out this patch *does* fix it:

diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
index 9afd6714f0d..38282e58f10 100644
--- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
+++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
@@ -3,7 +3,7 @@ HOMEPAGE = "https://www.yoctoproject.org/"
 LICENSE = "GPL-2.0-only"
 LIC_FILES_CHKSUM = "file://${COREBASE}/meta/files/common-licenses/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6"
 
-inherit kernel-arch
+inherit kernel-arch linux-kernel-base
 inherit pkgconfig
 
 PACKAGE_ARCH = "${MACHINE_ARCH}"


Cheers,

Richard