[PATCH v2 0/2] fix the SDK kernel module test

[PATCH v2 0/2] fix the SDK kernel module test

[Trevor Woerner]

The kernel module test in the SDK test suite does not pass today.

The cryptodev revision it builds no longer builds against kernel 6.18,
and the kernel's host tools are compiled with a pkg-config that the SDK
environment has pointed at the target sysroot, so a host compile is
handed target include paths and fails under -Werror. OE-Core already
solves the second one for its own kernel builds, where kernel.bbclass
passes HOSTPKG_CONFIG=pkg-config-native; the SDK simply had no
equivalent.

These are independent of any SDK feature work and fix a test that is
broken in master today.

Changes in v2:
 - the SDK environment script no longer exports HOSTPKG_CONFIG. That
   half only ever took effect against a proposed kernel change that has
   since been abandoned, so nothing honoured it. The make command line
   assignment, which is what makes the test work, is unchanged
 - the second patch loses its toolchain-scripts subject prefix, since it
   no longer touches that file

Signed-off-by: Trevor Woerner <twoerner@gmail.com>

Trevor Woerner (2):
  oeqa/sdk: update cryptodev to a revision that builds on kernel 6.18
  oeqa/sdk: build the kernel's host tools with a host pkg-config

 meta/lib/oeqa/sdk/cases/kmod.py | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

-- 
2.50.0.173.g8b6f19ccfc3a

[PATCH v2 1/2] oeqa/sdk: update cryptodev to a revision that builds on kernel 6.18

[Trevor Woerner]

The out-of-tree kernel module test pins a cryptodev-linux revision from
before the 1.14 release, which predates the removal of
crypto_ahash_alignmask() from the kernel and so no longer compiles:

  cryptlib.c:384:28: error: implicit declaration of function
  'crypto_ahash_alignmask' [-Wimplicit-function-declaration]

Move to upstream's "Fix build for Linux 6.18-rc1", which is the revision
that restores compatibility.

AI-Generated: codex/claude-opus 5 (xhigh)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
changes in v2:
- none
---
 meta/lib/oeqa/sdk/cases/kmod.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/sdk/cases/kmod.py b/meta/lib/oeqa/sdk/cases/kmod.py
index 0c4d8ddb543f..1be23e994fd2 100644
--- a/meta/lib/oeqa/sdk/cases/kmod.py
+++ b/meta/lib/oeqa/sdk/cases/kmod.py
@@ -31,8 +31,8 @@ class KernelModuleTest(OESDKTestCase):
 
         with tempfile.TemporaryDirectory(prefix="cryptodev", dir=self.tc.sdk_dir) as testdir:
             git_url = "https://github.com/cryptodev-linux/cryptodev-linux"
-            # This is a knnown-good commit post-1.13 that builds with kernel 6.7+
-            git_sha = "bb8bc7cf60d2c0b097c8b3b0e807f805b577a53f"
+            # This is a known-good commit post-1.14 that builds with kernel 6.18+
+            git_sha = "08644db02d43478f802755903212f5ee506af73b"
 
             sourcedir = os.path.join(testdir, "cryptodev-linux")
             subprocess.check_output(["git", "clone", git_url, sourcedir], stderr=subprocess.STDOUT)
-- 
2.50.0.173.g8b6f19ccfc3a

Re: [PATCH v2 1/2] oeqa/sdk: update cryptodev to a revision that builds on kernel 6.18

[Paul Barker]

On Wed, 2026-08-12 at 23:05 -0400, Trevor Woerner wrote:
> The out-of-tree kernel module test pins a cryptodev-linux revision from
> before the 1.14 release, which predates the removal of
> crypto_ahash_alignmask() from the kernel and so no longer compiles:
> 
>   cryptlib.c:384:28: error: implicit declaration of function
>   'crypto_ahash_alignmask' [-Wimplicit-function-declaration]
> 
> Move to upstream's "Fix build for Linux 6.18-rc1", which is the revision
> that restores compatibility.
> 
> AI-Generated: codex/claude-opus 5 (xhigh)
> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> ---
> changes in v2:
> - none
> ---
>  meta/lib/oeqa/sdk/cases/kmod.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/lib/oeqa/sdk/cases/kmod.py b/meta/lib/oeqa/sdk/cases/kmod.py
> index 0c4d8ddb543f..1be23e994fd2 100644
> --- a/meta/lib/oeqa/sdk/cases/kmod.py
> +++ b/meta/lib/oeqa/sdk/cases/kmod.py
> @@ -31,8 +31,8 @@ class KernelModuleTest(OESDKTestCase):
>  
>          with tempfile.TemporaryDirectory(prefix="cryptodev", dir=self.tc.sdk_dir) as testdir:
>              git_url = "https://github.com/cryptodev-linux/cryptodev-linux"
> -            # This is a knnown-good commit post-1.13 that builds with kernel 6.7+
> -            git_sha = "bb8bc7cf60d2c0b097c8b3b0e807f805b577a53f"
> +            # This is a known-good commit post-1.14 that builds with kernel 6.18+
> +            git_sha = "08644db02d43478f802755903212f5ee506af73b"
>  
>              sourcedir = os.path.join(testdir, "cryptodev-linux")
>              subprocess.check_output(["git", "clone", git_url, sourcedir], stderr=subprocess.STDOUT)

Hi Trevor,

I'm wondering why we haven't spotted this issue previously, we've been
using Linux 6.18 for months now. Are we missing a test case?

Best regards,

-- 
Paul Barker

Re: [OE-core] [PATCH v2 1/2] oeqa/sdk: update cryptodev to a revision that builds on kernel 6.18

[Alexander Kanavin]

On Sun, 16 Aug 2026 at 13:12, Paul Barker via lists.openembedded.org
<paul=pbarker.dev@lists.openembedded.org> wrote:

> I'm wondering why we haven't spotted this issue previously, we've been
> using Linux 6.18 for months now. Are we missing a test case?

I suspect it's because the execution of useful cases for sdk and image
runtimes tends to regress due to 'soft-skip', e.g. if a needed package
isn't present, the test isn't run. I don't think this is quite right,
and each particular image and sdk should check that particular tests
do run, and if they aren't, that's a fail in itself. I'm not yet sure
how to technically implement this.

Alex

Re: [OE-core] [PATCH v2 1/2] oeqa/sdk: update cryptodev to a revision that builds on kernel 6.18

[Richard Purdie]

On Mon, 2026-08-17 at 12:51 +0200, Alexander Kanavin via lists.openembedded.org wrote:
> On Sun, 16 Aug 2026 at 13:12, Paul Barker via lists.openembedded.org
> <paul=pbarker.dev@lists.openembedded.org> wrote:
> 
> > I'm wondering why we haven't spotted this issue previously, we've been
> > using Linux 6.18 for months now. Are we missing a test case?
> 
> I suspect it's because the execution of useful cases for sdk and image
> runtimes tends to regress due to 'soft-skip', e.g. if a needed package
> isn't present, the test isn't run. I don't think this is quite right,
> and each particular image and sdk should check that particular tests
> do run, and if they aren't, that's a fail in itself. I'm not yet sure
> how to technically implement this.

I've worried about this for a while too.

We really need to mark up the images with the lists of tests we expect
to pass. It is tricky as that list can vary depending on distro
features and package classes but should be possible.

The other option is to have resulttool have more checks where it
compares to a list of tests we should see running. The regression
report is supposed to partly handle that but if you miss a regression,
the difference will no longer show it...

Cheers,

Richard

Re: [OE-core] [PATCH v2 1/2] oeqa/sdk: update cryptodev to a revision that builds on kernel 6.18

[Trevor Woerner]

On Mon 2026-08-17 @ 01:48:55 PM, Richard Purdie wrote:
> On Mon, 2026-08-17 at 12:51 +0200, Alexander Kanavin via lists.openembedded.org wrote:
> > On Sun, 16 Aug 2026 at 13:12, Paul Barker via lists.openembedded.org
> > <paul=pbarker.dev@lists.openembedded.org> wrote:
> > 
> > > I'm wondering why we haven't spotted this issue previously, we've been
> > > using Linux 6.18 for months now. Are we missing a test case?
> > 
> > I suspect it's because the execution of useful cases for sdk and image
> > runtimes tends to regress due to 'soft-skip', e.g. if a needed package
> > isn't present, the test isn't run. I don't think this is quite right,
> > and each particular image and sdk should check that particular tests
> > do run, and if they aren't, that's a fail in itself. I'm not yet sure
> > how to technically implement this.
> 
> I've worried about this for a while too.
> 
> We really need to mark up the images with the lists of tests we expect
> to pass. It is tricky as that list can vary depending on distro
> features and package classes but should be possible.

Agreed on the goal. Having gone through what the cases actually do, I
want to be careful about how much of it one mechanism can cover, because
the skips are not all the same shape.

Some are a stated requirement. cmake, gtk3, kmod, maturin, meson, perl
and python each name a package and skip when the SDK's manifest does not 
list it. Those are already machine-readable, and one narrow check on
them looks worth having by itself: if a case names a requirement, the 
manifest satisfies it, and the case skips anyway, that is a bug rather
than a configuration. That is exactly what the twelve above were, and 
catching it needs no per-image expected list.

The rest are not declarations at all. autotools, cmake, gcc, makefile
and meson skip on "SDK doesn't contain a supported C library"; gcc, go
and rust skip on not finding a cross-canadian toolchain; go also skips
when the command raises. Those are runtime probes of the SDK that was 
installed, and marking up an image cannot say in advance what they will
decide. The go and rust cases are among the ones that skip on a default
SDK, so this is not a rare shape.

So I do not think declarations on their own produce the expected-test
list, and I would rather say that now than discover it half way through.
The configuration-dependence you name looks like the hard part, and I do
not have a design for it. 

What I am willing to commit to is the narrow check above, since the 
oeqa/sdk change it builds on is already written. If that seems useful I
will send it as its own patch and we can see whether it earns its keep
before anyone builds anything larger on top.

> The other option is to have resulttool have more checks where it
> compares to a list of tests we should see running. The regression
> report is supposed to partly handle that but if you miss a regression,
> the difference will no longer show it...
> 
> Cheers,
> 
> Richard

Re: [PATCH v2 1/2] oeqa/sdk: update cryptodev to a revision that builds on kernel 6.18

[Trevor Woerner]

On Sun 2026-08-16 @ 12:12:49 PM, Paul Barker wrote:
> On Wed, 2026-08-12 at 23:05 -0400, Trevor Woerner wrote:
> > The out-of-tree kernel module test pins a cryptodev-linux revision from
> > before the 1.14 release, which predates the removal of
> > crypto_ahash_alignmask() from the kernel and so no longer compiles:
> > 
> >   cryptlib.c:384:28: error: implicit declaration of function
> >   'crypto_ahash_alignmask' [-Wimplicit-function-declaration]
> > 
> > Move to upstream's "Fix build for Linux 6.18-rc1", which is the revision
> > that restores compatibility.
> > 
> > AI-Generated: codex/claude-opus 5 (xhigh)
> > Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> > ---
> > changes in v2:
> > - none
> > ---
> >  meta/lib/oeqa/sdk/cases/kmod.py | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meta/lib/oeqa/sdk/cases/kmod.py b/meta/lib/oeqa/sdk/cases/kmod.py
> > index 0c4d8ddb543f..1be23e994fd2 100644
> > --- a/meta/lib/oeqa/sdk/cases/kmod.py
> > +++ b/meta/lib/oeqa/sdk/cases/kmod.py
> > @@ -31,8 +31,8 @@ class KernelModuleTest(OESDKTestCase):
> >  
> >          with tempfile.TemporaryDirectory(prefix="cryptodev", dir=self.tc.sdk_dir) as testdir:
> >              git_url = "https://github.com/cryptodev-linux/cryptodev-linux"
> > -            # This is a knnown-good commit post-1.13 that builds with kernel 6.7+
> > -            git_sha = "bb8bc7cf60d2c0b097c8b3b0e807f805b577a53f"
> > +            # This is a known-good commit post-1.14 that builds with kernel 6.18+
> > +            git_sha = "08644db02d43478f802755903212f5ee506af73b"
> >  
> >              sourcedir = os.path.join(testdir, "cryptodev-linux")
> >              subprocess.check_output(["git", "clone", git_url, sourcedir], stderr=subprocess.STDOUT)
> 
> Hi Trevor,
> 
> I'm wondering why we haven't spotted this issue previously, we've been
> using Linux 6.18 for months now. Are we missing a test case?

No, the test case is there. It has been skipping, and a skip and a pass
look the same from the summary line.

kmod.KernelModuleTest guards on

    self.ensure_target_package("kernel-devsrc")

and a standard SDK does not contain kernel-devsrc, so that test has 
never run on the SDK the autobuilder actually builds. It only ran here
because I was building an SDK that carries the kernel source, which is
also why the cryptodev breakage surfaced now rather than in March.

It is not an isolated case. Here is a second one, entirely in current
master:

    meta/lib/oeqa/sdk/cases/meson.py:28
        self.ensure_host_package("pkgconfig")

ensure_host_package() prefixes the name and looks the result up in the 
SDK's host manifest by exact package name. The manifest has 
nativesdk-pkgconf. It has had nativesdk-pkgconf since e32bf38fab8b
"pkgconfig: remove" on 2026-03-23, so meson.MesonTest.test_iputils has 
been skipping on every SDK for five months. RPROVIDES does not help,
because the manifest records the names of the packages that were
installed rather than what they provide.

The two have different causes and the same symptom, and neither is
visible: one test is gated on content a standard SDK does not have, and 
the other on a package name that was renamed underneath it. 

The shape of the exposure is that 7 of the 13 oeqa/sdk modules on master
carry an ensure_host_package() or ensure_target_package() guard: cmake,
gtk3, kmod, maturin, meson, perl and python. Each of those can stop
running without anything turning red.

There is a second failure mode that is worse than a skip, and I only
found it by looking for the first. An eSDK's host manifest is written by
write_host_sdk_ext_manifest(), which walks the sstate cache the eSDK
ships and prints every object built for BUILD_SYS. So it lists what the
eSDK could install, not what it has. A guard checking that manifest
therefore passes, the test runs the command anyway, and it gets the
build machine's copy: perl.PerlTest reports on the build host's
interpreter rather than the SDK's. That is a green result for something
the SDK never provided, and no amount of counting skips will catch it.

I have been down a deep rabbit hole finding and fixing many of these
things while working on my SDK_FEATURES patchset:

- a fix for the pkgconf name above, so the meson case runs again
- an oeqa/sdk change letting a case name the command it needs and
  resolve it inside the SDK's own install directory, so "the SDK does
  not have this" and "I silently used the host's copy" stop being the
  same outcome. That is what turns the eSDK false pass into either a
  real pass or an honest skip.

That mistake is an easy one to make, and here is one measurement. In a
branch here that adds more SDK feature tests, applying that command
check turned twelve cases from skipping to running, and every one of the
packages involved was already installed in the SDK. They were skipping
because the check asserted a command named after the package, and
bindgen-cli provides bindgen, shaderc provides glslc, spirv-tools-bin
provides spirv-val, python3-spdx-tools provides pyspdxtools, and
mesa-libclc provides no command at all. That is twelve tests, no missing
packages, and nothing red. I am not claiming those twelve are yours,
because they are not upstream yet. I am claiming that the failure mode
is easy to write and impossible to see, which is the part that
generalises.


> Best regards,
> 
> -- 
> Paul Barker
> 

Re: [PATCH v2 1/2] oeqa/sdk: update cryptodev to a revision that builds on kernel 6.18

[Paul Barker]

On Sat, 2026-08-22 at 10:52 -0400, Trevor Woerner wrote:
> On Sun 2026-08-16 @ 12:12:49 PM, Paul Barker wrote:
> > On Wed, 2026-08-12 at 23:05 -0400, Trevor Woerner wrote:
> > > The out-of-tree kernel module test pins a cryptodev-linux revision from
> > > before the 1.14 release, which predates the removal of
> > > crypto_ahash_alignmask() from the kernel and so no longer compiles:
> > > 
> > >   cryptlib.c:384:28: error: implicit declaration of function
> > >   'crypto_ahash_alignmask' [-Wimplicit-function-declaration]
> > > 
> > > Move to upstream's "Fix build for Linux 6.18-rc1", which is the revision
> > > that restores compatibility.
> > > 
> > > AI-Generated: codex/claude-opus 5 (xhigh)
> > > Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> > > ---
> > > changes in v2:
> > > - none
> > > ---
> > >  meta/lib/oeqa/sdk/cases/kmod.py | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/meta/lib/oeqa/sdk/cases/kmod.py b/meta/lib/oeqa/sdk/cases/kmod.py
> > > index 0c4d8ddb543f..1be23e994fd2 100644
> > > --- a/meta/lib/oeqa/sdk/cases/kmod.py
> > > +++ b/meta/lib/oeqa/sdk/cases/kmod.py
> > > @@ -31,8 +31,8 @@ class KernelModuleTest(OESDKTestCase):
> > >  
> > >          with tempfile.TemporaryDirectory(prefix="cryptodev", dir=self.tc.sdk_dir) as testdir:
> > >              git_url = "https://github.com/cryptodev-linux/cryptodev-linux"
> > > -            # This is a knnown-good commit post-1.13 that builds with kernel 6.7+
> > > -            git_sha = "bb8bc7cf60d2c0b097c8b3b0e807f805b577a53f"
> > > +            # This is a known-good commit post-1.14 that builds with kernel 6.18+
> > > +            git_sha = "08644db02d43478f802755903212f5ee506af73b"
> > >  
> > >              sourcedir = os.path.join(testdir, "cryptodev-linux")
> > >              subprocess.check_output(["git", "clone", git_url, sourcedir], stderr=subprocess.STDOUT)
> > 
> > Hi Trevor,
> > 
> > I'm wondering why we haven't spotted this issue previously, we've been
> > using Linux 6.18 for months now. Are we missing a test case?
> 
> No, the test case is there. It has been skipping, and a skip and a pass
> look the same from the summary line.
> 
> kmod.KernelModuleTest guards on
> 
>     self.ensure_target_package("kernel-devsrc")
> 
> and a standard SDK does not contain kernel-devsrc, so that test has 
> never run on the SDK the autobuilder actually builds. It only ran here
> because I was building an SDK that carries the kernel source, which is
> also why the cryptodev breakage surfaced now rather than in March.

Good catch!

> I have been down a deep rabbit hole finding and fixing many of these
> things while working on my SDK_FEATURES patchset:
> 
> - a fix for the pkgconf name above, so the meson case runs again
> - an oeqa/sdk change letting a case name the command it needs and
>   resolve it inside the SDK's own install directory, so "the SDK does
>   not have this" and "I silently used the host's copy" stop being the
>   same outcome. That is what turns the eSDK false pass into either a
>   real pass or an honest skip.

I look forward to the patches!

In the meantime we can merge this patch as we now understand why we
weren't seeing any failures.

Best regards,

-- 
Paul Barker

[PATCH v2 2/2] oeqa/sdk: build the kernel's host tools with a host pkg-config

[Trevor Woerner]

The SDK environment sets PKG_CONFIG_SYSROOT_DIR, PKG_CONFIG_PATH and
PKG_CONFIG_LIBDIR so that pkg-config answers for the target. That is
right for everything built to run there and wrong for a program built to
run on the SDK host.

The kernel build compiles host tools of its own, and objtool asks
pkg-config where libelf is. It gets the target's include directory,
compiles a host tool against the target's C library headers, and stops
on warnings that -Wno-system-headers would otherwise have covered:

  usr/include/sys/cdefs.h:486: error: "__attribute_const__" redefined

Pass a pkg-config that undoes those three variables on the make command
line when the test builds an external module. It has to be a command
line assignment: the kernel assigns HOSTPKG_CONFIG with '=', so an
exported value is ignored. OE-Core already does the same thing for its
own kernel builds, in kernel.bbclass.

Fixes [YOCTO #16239].

AI-Generated: codex/claude-opus 5 (xhigh)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
changes in v2:
- drop the HOSTPKG_CONFIG export from the SDK environment script. It
  only ever took effect against a proposed kernel change that has since
  been abandoned, so no kernel honours it and it was dead weight. The
  make command line assignment, which is what makes the test work, is
  unchanged
- the subject loses its toolchain-scripts prefix, since that file is no
  longer touched
- drop the paragraph citing the kernel proposal
---
 meta/lib/oeqa/sdk/cases/kmod.py | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/sdk/cases/kmod.py b/meta/lib/oeqa/sdk/cases/kmod.py
index 1be23e994fd2..1d73f076e552 100644
--- a/meta/lib/oeqa/sdk/cases/kmod.py
+++ b/meta/lib/oeqa/sdk/cases/kmod.py
@@ -26,8 +26,11 @@ class KernelModuleTest(OESDKTestCase):
         parallel_make = "-j %d" % (pmv) if pmv else ""
 
         self.ensure_target_package("kernel-devsrc")
+        # the kernel assigns HOSTPKG_CONFIG with '=', so it has to come from
+        # the make command line, as kernel.bbclass does
+        host_pkg_config = 'HOSTPKG_CONFIG="env -u PKG_CONFIG_SYSROOT_DIR -u PKG_CONFIG_PATH -u PKG_CONFIG_LIBDIR pkg-config"'
         # These targets need to be built before kernel modules can be built.
-        self._run("make %s -C $OECORE_TARGET_SYSROOT/usr/src/kernel prepare scripts" % (parallel_make))
+        self._run("make %s %s -C $OECORE_TARGET_SYSROOT/usr/src/kernel prepare scripts" % (parallel_make, host_pkg_config))
 
         with tempfile.TemporaryDirectory(prefix="cryptodev", dir=self.tc.sdk_dir) as testdir:
             git_url = "https://github.com/cryptodev-linux/cryptodev-linux"
@@ -39,5 +42,5 @@ class KernelModuleTest(OESDKTestCase):
             self.assertTrue(os.path.isdir(sourcedir))
             subprocess.check_output(["git", "-C", sourcedir, "checkout", git_sha], stderr=subprocess.STDOUT)
 
-            self._run("make -C %s V=1 KERNEL_DIR=$OECORE_TARGET_SYSROOT/usr/src/kernel" % sourcedir)
+            self._run("make -C %s V=1 %s KERNEL_DIR=$OECORE_TARGET_SYSROOT/usr/src/kernel" % (sourcedir, host_pkg_config))
             self.check_elf(os.path.join(sourcedir, "cryptodev.ko"))
-- 
2.50.0.173.g8b6f19ccfc3a