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. > 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. > 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. > (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. > > 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. [...] > > 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. > > > 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. Thanks, Song
