On Fri, 2017-10-20 at 14:07 +0200, Torsten Duwe wrote:

On Wed, Oct 18, 2017 at 11:47:35AM +0530, Kamalesh Babulal wrote:

quoted

Consider a trivial patch, supplied to kpatch tool for generating a
livepatch module:

--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c

@@ -132,7 +132,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
        seq_printf(m, "VmallocTotal:   %8lu kB\n",
                   (unsigned long)VMALLOC_TOTAL >> 10);
        show_val_kb(m, "VmallocUsed:    ", 0ul);
-       show_val_kb(m, "VmallocChunk:   ", 0ul);
+       show_val_kb(m, "VMALLOCCHUNK:   ", 0ul);

Am I assuming correctly that "kpatch tool" simply recompiles all code the
way it would get compiled in a regular kernel build?

kpatch is open source and is available on github. This patch is specific
to the way kpatch works

My understanding is
that live patching modules need to be carefully prepared, which involves
source code reorganisation and recompilation. In that process, you can
easily declare show_val_kb() extern, and get the suitable instruction sequence
for the call.

Yes, we agree. For the current versions of kpatch, which involve a process of
applying the patch and building the kernel without and with the patch and doing
an elf diff (programatically), we cannot deviate from that process as it's
architecture independent. This patch solves arch specific issues related
to that process.

You have CC'ed live-patching. A discussion about how to automate this very
process is currently going on there. May I suggest you subscribe to that if
you are interested.

We are interested, can you point us to the archives. While we do follow that
thread, this patch is independent of future changes and enables kpatch
today and enables certain workflows

	Torsten

Thanks for your review
Balbir Singh.