[PATCH v2] kernel/module_64.c: Add REL24 relocation support of livepatch symbols

[Balbir Singh]

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:
> > 
> > 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.