Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1377902 > unrolled thread
| Started by | Michael Ellerman <mpe@ellerman.id.au> |
|---|---|
| First post | 2016-04-13 15:00 +0200 |
| Last post | 2016-04-15 12:10 +0200 |
| Articles | 10 on this page of 30 — 7 participants |
Back to article view | Back to linux.kernel
[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]
| From | Jiri Kosina <jikos@kernel.org> |
|---|---|
| Date | 2016-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]
| From | Michael Ellerman <mpe@ellerman.id.au> |
|---|---|
| Date | 2016-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]
| From | Jiri Kosina <jikos@kernel.org> |
|---|---|
| Date | 2016-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]
| From | Balbir Singh <bsingharora@gmail.com> |
|---|---|
| Date | 2016-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]
| From | Jiri Kosina <jikos@kernel.org> |
|---|---|
| Date | 2016-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]
| From | Jessica Yu <jeyu@redhat.com> |
|---|---|
| Date | 2016-04-13 20:30 +0200 |
| Subject | Re: 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]
| From | Miroslav Benes <mbenes@suse.cz> |
|---|---|
| Date | 2016-04-14 15:30 +0200 |
| Subject | Re: 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]
| From | Jessica Yu <jeyu@redhat.com> |
|---|---|
| Date | 2016-04-14 21:30 +0200 |
| Subject | Re: 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]
| From | Miroslav Benes <mbenes@suse.cz> |
|---|---|
| Date | 2016-04-15 10:30 +0200 |
| Subject | Re: 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]
| From | Michael Ellerman <mpe@ellerman.id.au> |
|---|---|
| Date | 2016-04-15 12:10 +0200 |
| Subject | Re: 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