Hi Sami, On Tue, Jun 16, 2026 at 07:15:03PM +0000, Samiullah Khawaja wrote: > On Mon, Jun 01, 2026 at 10:00:05AM +0300, Mike Rapoport wrote: > > Hi Samiullah, > > > > On Thu, May 21, 2026 at 07:31:59PM +0000, Samiullah Khawaja wrote: > > > To write kunit tests for preservation and restoration of liveupdate > > > state in various subsystems without triggering the actual kexec, the KHO > > > restore API needs to be mocked by the test writer. The mocking is done > > > to allow testing of the individual components or functions in isolation. > > > > > > The patch series adds the following to support kunit testing when using > > > the KHO > > > API: > > > > > > - Add static stub hooks to mock the KHO restore API so the restore path > > > can be tested without triggering kexec. > > > - Add helper function that can be used by the test writer to check if > > > memory is preserved in KHO tree. > > > > > > Finally, it adds a KUnit test for the KHO API that verifies the > > > allocation of > > > preserved memory, and the preservation/restoration of pages and folios. > > > > I looked at the tests for preservation and apparently they don't add > > coverage beyond the existing KHO selftest. How hard and/or intrusive would > > be adding tests for example for error paths? > > > > Do you have an example of a kunit test for another subsystem that would > > benefit from mocking of KHO APIs? > > I think intrusive tests to get more coverage for KHO would probably not > use the stubs added in this series, as these are meant to mock the KHO > restore API itself. > > My motivation was to allow downstream users of KHO to test their own > preservation logic (making sure their ABI doesn't have bugs). LUO or the > recently added KHO linked-block can probably be a start? > > The KHO kunit test added here is just a minimum example of how to use the > stubs, which is why it doesn't provide much extra coverage. > > I am perfectly happy to drop this patch for now. We can get this in > later when we have kunit tests for KHO users. WDYT?
I wouldn't want to merge this upstream before the actual users appear, but we can apply this to a branch in the liveupdate tree and keep it there so that subsystems that plan to use these stubs could base their work on that branch. Let's revisit this after -rc1 is out. > Thanks, > Sami -- Sincerely yours, Mike.
