On Wed, Mar 04, 2026 at 03:12:48PM -0800, Song Liu wrote: > On Wed, Mar 4, 2026 at 11:33 AM Joe Lawrence <[email protected]> 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
