Re: [PATCH v3 8/8] livepatch: Add tests for klp-build toolchain

[Joe Lawrence <joe.lawrence@redhat.com>]

On Wed, Mar 04, 2026 at 03:12:48PM -0800, Song Liu wrote:
> On Wed, Mar 4, 2026 at 11:33 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> [...]
> 
> > I've been tinkering with ideas in this space, though I took it in a very
> > different direction.
> >
> > (First a disclaimer, this effort is largely the result of vibe coding
> > with Claude to prototype testing concepts, so I don't believe any of it
> > is reliable or upstream-worthy at this point.)
> >
> > From a top-down perspective, I might start with the generated test
> > reports:
> >
> > - https://file.rdu.redhat.com/~jolawren/artifacts/report.html
> > - https://file.rdu.redhat.com/~jolawren/artifacts/report.txt
> 
> I cannot access these two links.
> 

Gah, sorry about those internal links.

Try:

https://joe-lawrence.github.io/klp-build-selftest-artifacts/report.html
https://joe-lawrence.github.io/klp-build-selftest-artifacts/report.txt

> > and then in my own words:
> >
> [...]
> >
> > 5- Two patch targets:
> >
> > a) current-tree - target the user's current source tree
> > b) patched-tree - (temporarily) patch the user's tree to *exactly* what
> >                   we need to target
> >
> > Why?  In the kpatch-build project, patching the current-tree meant we
> > had to rebase patches for every release.  We also had to hunt and find
> > precise scenarios across the kernel tree to test, hoping they wouldn't
> > go away in future versions.  In other cases, the kernel or compiler
> > changed and we weren't testing the original problem any longer.
> 
> I would prefer making patched-tree as upstream + some different
> CONFIG_s. Otherwise, we will need to carry .patch files for the
> patched-tree in selftests, which seems weird.
> 

It is strange, but for my experiment, I wanted minimal disruption to the
tree.  For the "real" changeset, upstream + some testing CONFIG_ sounds
good to me.

> > That said, patching a dummy patched-tree isn't be perfect either,
> > particularly in the runtime sense.  You're not testing a release kernel,
> > but something slightly different.
> 
> This should not be a problem. The goal is to test the klp-build toolchain.
> 

Right, perhaps klp-build testing always targets a slightly modified
kernel (or at least CONFIG_) while livepatching testing operates against
the stock tree?

> > (Tangent: kpatch-build implemented a unit test scheme that cached object
> > files for even greater speed and fixed testing.  I haven't thought about
> > how a similar idea might work for klp-build.)
> 
> I think it is a good idea to have similar .o file tests for klp-diff
> in klp-build.
> 

kpatch-build uses a git submodule (a joy to work with /s), but maybe
upstream tree can fetch the binary objects from some external
(github/etc.) source?  I wonder if there is any kselftest precident for
this, we'll need to investigate that.

> >
> > 6- Two patch models:
> >
> > a) static .patch files
> > b) scripted .patch generation
> >
> > Why?  Sometimes a test like cmdline-string.patch is sufficient and
> > stable.  Other times it's not.  For example, the recount-many-file test
> > in this branch is implemented via a script.  This allows the test to be
> > dynamic and potentially avoid the rebasing problem mentioned above.
> 
> I think we can have both a) and b).
> 
> > 7- Build verification including ELF analysis.  Not very mature in this
> > branch, but it would be nice to be able to build on it:
> 
> If we test the behavior after loading the patches, ELF analysis might
> be optional. But we can also do both.
> 

Maybe, though doing so during the build test would give us that analysis
for future cross-compiled test cases without having to actually boot and
load them somewhere.

> [...]
> 
> >
> > 8- Probably more I've already forgotten about :) Cross-compilation may
> > be interesting for build testing in the future.  For the full AI created
> > commentary, there's https://github.com/joe-lawrence/linux/blob/klp-build-selftests/README.md
> 
> Yes, cross-compilation can be really useful.
> 

Agreed (I think Josh may be working on arm64 klp-build?) how many
dimensions of testing are we up to now :)

> > > > I was using kpatch for testing. I can replace it with insmod.
> > >
> >
> > Do the helpers in functions.sh for safely loading and unloading
> > livepatches (that wait for the transition, etc.) aid here?
> 
> Yes, we can reuse those.
> [...]
> 
> > To continue the bike shedding, in my branch, I had dumped this all under
> > a new tools/testing/klp-build subdirectory as my focus was to put
> > klp-build through the paces.  It does load the generated livepatches in
> > the runtime testing, but as only as a sanity check.  With that, it
> > didn't touch CONFIG or intermix testing with the livepatch/ set.
> >
> > If we do end up supplementing the livepatch/ with klp-build tests, then
> > I agree that naming them (either filename prefix or subdirectory) would
> > be nice.
> >
> > But first, is it goal for klp-build to be the build tool (rather than
> > simple module kbuild) for the livepatching .ko selftests?
> 
> I think we don't have to use klp-build for livepatch selftests. Existing
> tests work well as-is.
> 

--
Joe