Best way to build one livepatch with both in-tree and OOT fixes

[liu-song-6]

I am looking at the use case to build one livepatch for both in-tree fixes and OOT fixes. Why? Because we want to use the replace flag, and disallow loading more than one livepatches.

AFAICT, there are a few ways to do this:

1. We can allow feeding in .patch file for multiple source trees (1 for in-tree, and multiple OOTs). And build each of them in a single kpatch-build run.
2. We can also let one kpatch-build to dump tmp_output.o, and feed that into another kpatch-build run (and repeat this multiple times).
3. We can merge multiple klp.ko files.

I wonder whether somebody is already looking into this. If not, any suggestions on what would be the most promising direction?

Thanks in advance.

[jpoimboe]

Just an idea, before running kpatch-build I wonder if you could copy the OOT source into a subdir in the kernel tree and modify a kernel Makefile to traverse it in the build like an in-tree module.

[liu-song-6]

Interesting idea! I will give it a try.

[liu-song-6]

This works with some hack:

1. find_kobj() doesn't really work for the OOT module. I put a manual hack that matches .o file to .ko file;
2. OOT module depends on vmlinux. When kpatch-build builds patched source, all .o files in the OOT modules are built. As a result, kpatch-build runs binary diff on all .o files.
3. OOT modules may have different tricks in the Makefile. I had to apply some hacks to make it work.

For long term, what do you think about the tmp_output.o idea?

2. We can also let one kpatch-build to dump tmp_output.o, and feed that into another kpatch-build run (and repeat this multiple times).

[jpoimboe]

find_kobj() doesn't really work for the OOT module. I put a manual hack that matches .o file to .ko file;

Right, I have a pending PR which also does that. When building a patch for an OOT module, the parent .ko file will always be the OOT module.

OOT module depends on vmlinux. When kpatch-build builds patched source, all .o files in the OOT modules are built. As a result, kpatch-build runs binary diff on all .o files.

Hm, can you give more of an explanation of why this happens? It doesn't happen for in-tree modules (right?), so maybe something went wrong with the importing of the OOT module into the kernel tree.

OOT modules may have different tricks in the Makefile. I had to apply some hacks to make it work.

Yeah, I could see how that might be a problem. Though really, this kind of pain should be expected when dealing with OOT modules in general. One of many reasons OOT modules are bad.

For long term, what do you think about the tmp_output.o idea?

2. We can also let one kpatch-build to dump tmp_output.o, and feed that into another kpatch-build run (and repeat this multiple times).

I'm not crazy about it. It would be hard to come up with an interface that doesn't suck.

It would be interesting to try merging multiple .ko files. I wonder if it would be possible to just use objcopy somehow.