Re: [PATCH v2 0/3] kho: Add support for kunit mocking KHO restore API

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.