Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1379254

Re: Live patching for powerpc

Show all headers | View raw

+++ Miroslav Benes [14/04/16 15:28 +0200]:
>On Wed, 13 Apr 2016, Jessica Yu wrote:
>
>> +++ Miroslav Benes [13/04/16 15:01 +0200]:
>> > On Wed, 13 Apr 2016, Michael Ellerman wrote:
>> >
>> > > This series adds live patching support for powerpc (ppc64le only ATM).
>> > >
>> > > It's unchanged since the version I posted on March 24, with the exception
>> > > that
>> > > I've dropped the first patch, which was a testing-only patch.
>> > >
>> > > If there's no further comments I'll put this in a topic branch in the next
>> > > day
>> > > or two and Jiri & I will both merge that into next.
>> >
>> > Hi,
>> >
>> > I'll definitely give it a proper look today or tomorrow, but there is one
>> > thing that needs to be solved. The patch set from Jessica reworking
>> > relocations for live patching is now merged in our for-next branch. This
>> > means that we need to find out if there is something in struct
>> > mod_arch_specific for powerpc which needs to be preserved and do it.
>> >
>>
>> I took a look around the powerpc module.c code and it looks like the
>> mod_arch_specific stuff should be fine, since it is statically allocated
>> in the module struct (unlike the situation in s390, where
>> mod->arch.syminfo was vmalloc'd and we had to delay the free).
>> However I'm not familiar with the powerpc code so I need to dig around
>> a bit more to be 100% sure.
>
>I came to the same conclusion. There is only struct bug_entry *bug_table
>in mod_arch_specific but it looks unimportant wrt relocations.

Yeah, I think we are fine. As long as none of the values in
mod_arch_specific are "cleared," and I don't see that happening
anywhere.

>> A second concern I have is that apply_relocate_add() relies on
>> sections like .stubs and .toc (for 64-bit) and .init.plt and .plt
>> sections (for 32-bit). In order for apply_relocate_add() to work for
>> livepatch, we must make sure these sections aren't thrown away and are
>> not in init module memory since this memory will be freed at the end
>> of module load (see how INIT_OFFSET_MASK is used in kernel/module.c).
>> As long as these sections are placed in module core memory, we will be
>> OK. I need to think about this a bit more.
>
>I knew I shouldn't have opened arch/powerpc/kernel/module*.c.
>
>We could always hack sh_flags of those sections in
>module_arch_frob_sections() to make them stay.
>

I think we are fine here too. The onus would be on the patch build
tool (e.g., kpatch) to set the sh_flags to SHF_ALLOC, like we
already do to keep the klp relocation sections in memory :-)

For the 32-bit module code, I don't believe we would need to preserve
the .init.plt section for livepatch's call to apply_relocate_add(),
since relocations to init sections should've been applied during
module initialization, and we don't patch those types of functions.
Please correct me if my understanding is off.

Jessica

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH 0/5] Live patching for powerpc Michael Ellerman <mpe@ellerman.id.au> - 2016-04-13 15:00 +0200
  [PATCH 3/5] powerpc/livepatch: Add livepatch header Michael Ellerman <mpe@ellerman.id.au> - 2016-04-13 15:00 +0200
    Re: [PATCH 3/5] powerpc/livepatch: Add livepatch header Miroslav Benes <mbenes@suse.cz> - 2016-04-14 14:20 +0200
      Re: [PATCH 3/5] powerpc/livepatch: Add livepatch header Miroslav Benes <mbenes@suse.cz> - 2016-04-14 14:30 +0200
        Re: [PATCH 3/5] powerpc/livepatch: Add livepatch header Michael Ellerman <mpe@ellerman.id.au> - 2016-04-14 15:20 +0200
  [PATCH 1/5] ftrace: Make ftrace_location_range() global Michael Ellerman <mpe@ellerman.id.au> - 2016-04-13 15:00 +0200
  [PATCH 4/5] powerpc/livepatch: Add livepatch stack to struct thread_info Michael Ellerman <mpe@ellerman.id.au> - 2016-04-13 15:00 +0200
  Re: [PATCH 0/5] Live patching for powerpc Miroslav Benes <mbenes@suse.cz> - 2016-04-13 15:10 +0200
    Re: [PATCH 0/5] Live patching for powerpc Jiri Kosina <jikos@kernel.org> - 2016-04-13 15:30 +0200
      Re: [PATCH 0/5] Live patching for powerpc Michael Ellerman <mpe@ellerman.id.au> - 2016-04-14 09:00 +0200
        Re: [PATCH 0/5] Live patching for powerpc Torsten Duwe <duwe@lst.de> - 2016-04-14 15:00 +0200
          Re: [PATCH 0/5] Live patching for powerpc Michael Ellerman <mpe@ellerman.id.au> - 2016-04-14 15:10 +0200
            Re: [PATCH 0/5] Live patching for powerpc Torsten Duwe <duwe@lst.de> - 2016-04-14 17:30 +0200
              Re: [PATCH 0/5] Live patching for powerpc Josh Poimboeuf <jpoimboe@redhat.com> - 2016-04-14 18:50 +0200
                Re: [PATCH 0/5] Live patching for powerpc Michael Ellerman <mpe@ellerman.id.au> - 2016-04-15 13:30 +0200
                Re: [PATCH 0/5] Live patching for powerpc Josh Poimboeuf <jpoimboe@redhat.com> - 2016-04-15 15:00 +0200
                Re: [PATCH 0/5] Live patching for powerpc Michael Ellerman <mpe@ellerman.id.au> - 2016-04-15 15:30 +0200
          Re: [PATCH 0/5] Live patching for powerpc Jiri Kosina <jikos@kernel.org> - 2016-04-14 16:40 +0200
            Re: [PATCH 0/5] Live patching for powerpc Michael Ellerman <mpe@ellerman.id.au> - 2016-04-15 14:30 +0200
        Re: [PATCH 0/5] Live patching for powerpc Jiri Kosina <jikos@kernel.org> - 2016-04-15 17:10 +0200
    Re: Live patching for powerpc Jessica Yu <jeyu@redhat.com> - 2016-04-13 20:30 +0200
      Re: Live patching for powerpc Miroslav Benes <mbenes@suse.cz> - 2016-04-14 15:30 +0200
        Re: Live patching for powerpc Jessica Yu <jeyu@redhat.com> - 2016-04-14 21:30 +0200
          Re: Live patching for powerpc Miroslav Benes <mbenes@suse.cz> - 2016-04-15 10:30 +0200
            Re: Live patching for powerpc Michael Ellerman <mpe@ellerman.id.au> - 2016-04-15 12:10 +0200

csiph-web