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

[Trevor Woerner <twoerner@gmail.com>]

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
>