Hi Yulia,

A quick question about the visibility and importance of this issue.

- RHEL-8 compresses kernel-* RPM provided module .ko files manually in the kernel specfile, and not via kernel CONFIG_MODULE_COMPRESS
- Without CONFIG_MODULE_COMPRESS, all Red Hat provided kpatch-patch RPMs only provide uncompressed kpatch.ko files

So I think this is not an issue any Red Hat kpatch-patch user would encounter, at least by installing official kpatch-patch RPMs that we release.

That said, the use case in Comment #0 looks like it enables new testing.  I don't think the fix will be too difficult upstream, but I'm wondering how critical it would be to backport and then to which releases?

I experimented some more with CONFIG_MODULE_COMPRESS_XZ=y:

  - Module .ko files are only compressed when running the kernel's
    "modules_install" target

     - kpatch-build doesn't run "modules_install", it copies the original
      .ko from the out of tree module dir (~/.kpatch/tmp/patch) to the
      current working dir

  - Even if one were to run "make -C /lib/modules/`uname -r`/build
    M=~/.kpatch/tmp/patch modules_install", a compressed .ko would be
    installed to /lib/modules/$(uname -r)/extra/

     - This is not kpatch utility's $INSTALLDIR, /var/lib/kpatch/$(uname
       -r)/, so the utility won't find this compressed module for use in
       any of its sub-commands

  - If we were to add module compression support to kpatch-build, it
    would look more like the RHEL kernel specfile, where it's
    post-processed outside of kbuild.

      - We would need to update kpatch utility in a few ways:

        - handle .ko{.gz,.xz} filename extensions
        - decompress before issuing any binutils or elfutils commands,
          like readelf
        - verify that debuginfo properly handles compression

I don't think any of this is impossible, but would require some time to
build and test through the whole pipeline (github, kpatch utility,
kpatch-patch generation, etc).


Thinking some more on this, the module you're trying to load is a
pure livepatch module and not a kpatch-module.  I wonder if makes more
sense to use a separate utility to handle them.

Somewhere I have a prototype that extracts interesting functions from
the kernel's tools/testing/selftests/livepatch/functions.sh file.  This
would allow a user to say "klp load <name>" and like kpatch-utility, it
will block until the module has fully loaded and its transition
complete.

I guess the next step(s) depend on the full use case.  Are you looking
to verify kpatch utility behavior with test_klp_livepatch.ko.xz, kernel
behavior, or something else?

Hi, Joe. 

As you pointed out this is not a customer use case. 
I was under wrong impression that something is already implemented upstream.
Thank you for detailed explanation and please disregard this request.

Need to take a different approach for a test case I'm thinking of. 
Looking to add a lightweight test for kpatch utility that is run on nightly composes.
Will need a module to install, enable and load. 
Do not want to build kpatch modules as it requires a lot of dependencies to be installed and takes significant time. 

Unfortunately, we do not build kpatch-patch modules for each candidate kernel in ystream that could be utilized.

Please let me know your thoughts.

Hmm, using an uncompressed test_klp_livepatch.ko with kpatch utility may be the fastest way to implement this new test.  AFAIK there is nothing stopping kpatch-utility from install/enable/load-ing a pure livepatch, only that doing so isn't part of any integration test that we regularly run.  YMMV, but I bet it works :)

To do this with frequently created kpatch-livepatches will require some new automation.  The team has kicked around similar ideas in the past (for empty kpatches I think), so maybe this use case could be included as part of a larger goal.  I think this would make a good dev-team agenda item, though the next one isn't until Oct 28.  If you want to brainstorm sooner, we can start a thread on kpatch-team.

Thank you, Joe. 
Oct 28 is ok with me. I do not need it earlier. 
Can draft a test with test_klp_livepatch or previously built kpatch-patches

Please feel free to close this bz.