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


Groups > linux.kernel > #1377902 > unrolled thread

[PATCH 0/5] Live patching for powerpc

Started byMichael Ellerman <mpe@ellerman.id.au>
First post2016-04-13 15:00 +0200
Last post2016-04-15 12:10 +0200
Articles 10 on this page of 30 — 7 participants

Back to article view | Back to linux.kernel


Contents

  [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
      Re: [3/5] powerpc/livepatch: Add livepatch header Michael Ellerman <mpe@ellerman.id.au> - 2016-04-19 12:20 +0200
    [PATCH 1/5] ftrace: Make ftrace_location_range() global Michael Ellerman <mpe@ellerman.id.au> - 2016-04-13 15:00 +0200
      Re: [1/5] ftrace: Make ftrace_location_range() global Michael Ellerman <mpe@ellerman.id.au> - 2016-04-19 12:20 +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: [4/5] powerpc/livepatch: Add livepatch stack to struct thread_info Michael Ellerman <mpe@ellerman.id.au> - 2016-04-19 12:20 +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: [PATCH 0/5] Live patching for powerpc Balbir Singh <bsingharora@gmail.com> - 2016-04-19 23:50 +0200
              Re: [PATCH 0/5] Live patching for powerpc Jiri Kosina <jikos@kernel.org> - 2016-04-20 00:00 +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

Page 2 of 2 — ← Prev page 1 [2]


#1378947

FromJiri Kosina <jikos@kernel.org>
Date2016-04-14 16:40 +0200
Message-ID<rnQB5-33W-41@gated-at.bofh.it>
In reply to#1378813
On Thu, 14 Apr 2016, Torsten Duwe wrote:

> > > > > 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.
> 
> Confirmed. And it still works on top of 4.6-rc3, even with the 
> additional testing.

Thanks a lot for testing.

The imporant part here is testing on top of 
livepatching.git#for-4.7/arch-independent-klp-relocations as well.

I am pretty sure there will be adjustments needed for the merge, as we'll 
have to figure out which parts of ELF can't be thrown away and need to be 
preserved in order for the relocation entry to be successfully 
constructed.

Michael, I think this is an additional reason why the whole final pile 
will have to go through livepatching.git, as the merge with what we have 
in for-4.7/arch-independent-klp-relocations might not be completely 
trivial.

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [next] | [standalone]


#1379785

FromMichael Ellerman <mpe@ellerman.id.au>
Date2016-04-15 14:30 +0200
Message-ID<rob2O-2XS-13@gated-at.bofh.it>
In reply to#1378947
On Thu, 2016-04-14 at 16:34 +0200, Jiri Kosina wrote:
> On Thu, 14 Apr 2016, Torsten Duwe wrote:
> > > > > > 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.
> > 
> > Confirmed. And it still works on top of 4.6-rc3, even with the 
> > additional testing.
> 
> Thanks a lot for testing.
> 
> The imporant part here is testing on top of 
> livepatching.git#for-4.7/arch-independent-klp-relocations as well.
> 
> I am pretty sure there will be adjustments needed for the merge, as we'll 
> have to figure out which parts of ELF can't be thrown away and need to be 
> preserved in order for the relocation entry to be successfully 
> constructed.
> 
> Michael, I think this is an additional reason why the whole final pile 
> will have to go through livepatching.git, as the merge with what we have 
> in for-4.7/arch-independent-klp-relocations might not be completely 
> trivial.

Well it will go through both :)

I'll merge it into powerpc#next, and you can merge it into livepatching and do
what ever else is needed as part of, or after, that merge.

cheers

[toc] | [prev] | [next] | [standalone]


#1379903

FromJiri Kosina <jikos@kernel.org>
Date2016-04-15 17:10 +0200
Message-ID<rodxD-4ZA-13@gated-at.bofh.it>
In reply to#1378532
On Thu, 14 Apr 2016, Michael Ellerman wrote:

> Topic branch here:
> 
>   https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/log/?h=topic/livepatch
> 
> I will merge that before Monday (my time) if I don't hear any objections.

I've now pulled this into livepatching.git#for-4.7/livepatching-ppc64 and 
merged that branch into for-next as well.

That branch already contains all the relocation changes queued for 4.7, so 
as much testing of the merged result as possible on ppc64 would be 
appreciated.

Thanks everybody,

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [next] | [standalone]


#1382860

FromBalbir Singh <bsingharora@gmail.com>
Date2016-04-19 23:50 +0200
Message-ID<rpLGV-5dm-11@gated-at.bofh.it>
In reply to#1379903

On 16/04/16 01:07, Jiri Kosina wrote:
> On Thu, 14 Apr 2016, Michael Ellerman wrote:
> 
>> Topic branch here:
>>
>>   https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/log/?h=topic/livepatch
>>
>> I will merge that before Monday (my time) if I don't hear any objections.
> 
> I've now pulled this into livepatching.git#for-4.7/livepatching-ppc64 and 
> merged that branch into for-next as well.
> 
> That branch already contains all the relocation changes queued for 4.7, so 
> as much testing of the merged result as possible on ppc64 would be 
> appreciated.
Thanks, do we have a summary of what the relocation changes look like?

Balbir Singh.

[toc] | [prev] | [next] | [standalone]


#1382861

FromJiri Kosina <jikos@kernel.org>
Date2016-04-20 00:00 +0200
Message-ID<rpLQE-5jS-43@gated-at.bofh.it>
In reply to#1382860
On Wed, 20 Apr 2016, Balbir Singh wrote:

> Thanks, do we have a summary of what the relocation changes look like?

This work is queued in 
livepatching.git#for-4.7/arch-independent-klp-relocations

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [next] | [standalone]


#1378166 — Re: Live patching for powerpc

FromJessica Yu <jeyu@redhat.com>
Date2016-04-13 20:30 +0200
SubjectRe: Live patching for powerpc
Message-ID<rnxI6-5ve-21@gated-at.bofh.it>
In reply to#1377913
+++ 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.

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.

Third and unrelated comment: the klp_write_module_reloc stub isn't
needed anymore :-)

Thanks,
Jessica

[toc] | [prev] | [next] | [standalone]


#1378850 — Re: Live patching for powerpc

FromMiroslav Benes <mbenes@suse.cz>
Date2016-04-14 15:30 +0200
SubjectRe: Live patching for powerpc
Message-ID<rnPvm-2fL-57@gated-at.bofh.it>
In reply to#1378166
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.

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

Miroslav

> 
> Third and unrelated comment: the klp_write_module_reloc stub isn't
> needed anymore :-)
> 
> Thanks,
> Jessica
> 

[toc] | [prev] | [next] | [standalone]


#1379254 — Re: Live patching for powerpc

FromJessica Yu <jeyu@redhat.com>
Date2016-04-14 21:30 +0200
SubjectRe: Live patching for powerpc
Message-ID<rnV7J-77H-49@gated-at.bofh.it>
In reply to#1378850
+++ 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

[toc] | [prev] | [next] | [standalone]


#1379546 — Re: Live patching for powerpc

FromMiroslav Benes <mbenes@suse.cz>
Date2016-04-15 10:30 +0200
SubjectRe: Live patching for powerpc
Message-ID<ro7iy-8vH-17@gated-at.bofh.it>
In reply to#1379254
On Thu, 14 Apr 2016, Jessica Yu wrote:

> +++ Miroslav Benes [14/04/16 15:28 +0200]:
> > On Wed, 13 Apr 2016, Jessica Yu wrote:
> 
> > > 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 :-)

Yes, this is probably the best way.

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

I think you are right, but I also think we don't have to worry about 
32-bit powerpc anyway. This patch set supports ppc64le only so we can 
leave it for now.

Miroslav

[toc] | [prev] | [next] | [standalone]


#1379661 — Re: Live patching for powerpc

FromMichael Ellerman <mpe@ellerman.id.au>
Date2016-04-15 12:10 +0200
SubjectRe: Live patching for powerpc
Message-ID<ro8Rk-1jQ-7@gated-at.bofh.it>
In reply to#1379546
On Fri, 2016-04-15 at 10:28 +0200, Miroslav Benes wrote:
> On Thu, 14 Apr 2016, Jessica Yu wrote:
> > 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.
> 
> I think you are right, but I also think we don't have to worry about 
> 32-bit powerpc anyway. This patch set supports ppc64le only so we can 
> leave it for now.

Yep. Who ever wants to do 32-bit live patch support can cross that bridge when
they come to it.

cheers

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel


csiph-web