[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200420195111.ob7jnhs7wqp6d56g@treble>
Date: Mon, 20 Apr 2020 14:51:11 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Joe Lawrence <joe.lawrence@...hat.com>
Cc: live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Jessica Yu <jeyu@...nel.org>
Subject: Re: [PATCH v2 2/9] livepatch: Apply vmlinux-specific KLP relocations
early
On Mon, Apr 20, 2020 at 03:49:00PM -0400, Joe Lawrence wrote:
> On Mon, Apr 20, 2020 at 02:11:17PM -0500, Josh Poimboeuf wrote:
> > On Mon, Apr 20, 2020 at 03:01:41PM -0400, Joe Lawrence wrote:
> > > > > ... apply_relocations() is also iterating over the section headers (the
> > > > > diff context doesn't show it here, but i is an incrementing index over
> > > > > sechdrs[]).
> > > > >
> > > > > So if there is more than one KLP relocation section, we'll process them
> > > > > multiple times. At least the x86 relocation code will detect this and
> > > > > fail the module load with an invalid relocation (existing value not
> > > > > zero).
> > > >
> > > > Ah, yes, good catch!
> > > >
> > >
> > > The same test case passed with a small modification to push the foreach
> > > KLP section part to a kernel/livepatch/core.c local function and
> > > exposing the klp_resolve_symbols() + apply_relocate_add() for a given
> > > section to kernel/module.c. Something like following...
> >
> > I came up with something very similar, though I named them
> > klp_apply_object_relocs() and klp_apply_section_relocs() and changed the
> > argument order a bit (module first). Since it sounds like you have a
> > test, could you try this one?
> >
>
> LGTM. I have a few klp-convert selftests that I've been slowly
> tinkering on and they all load/run successfully with this version. :)
Good to hear, thanks! Hooray selftests :-)
--
Josh
Powered by blists - more mailing lists