From: Jessica Yu <jeyu@redhat.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
linuxppc-dev@ozlabs.org, bsingharora@gmail.com, duwe@lst.de,
linux-kernel@vger.kernel.org, rostedt@goodmis.org,
kamalesh@linux.vnet.ibm.com, pmladek@suse.com, jikos@kernel.org,
live-patching@vger.kernel.org
Subject: Re: Live patching for powerpc
Date: Wed, 13 Apr 2016 14:22:28 -0400 [thread overview]
Message-ID: <20160413182228.GA16776@packer-debian-8-amd64.digitalocean.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1604131457180.16586@pobox.suse.cz>
+++ 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
next prev parent reply other threads:[~2016-04-13 18:22 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-13 12:53 [PATCH 0/5] " Michael Ellerman
2016-04-13 12:53 ` [PATCH 1/5] ftrace: Make ftrace_location_range() global Michael Ellerman
2016-04-19 10:16 ` [1/5] " Michael Ellerman
2016-04-13 12:53 ` [PATCH 2/5] livepatch: Allow architectures to specify an alternate ftrace location Michael Ellerman
2016-04-14 12:01 ` Miroslav Benes
2016-04-14 13:06 ` Michael Ellerman
2016-04-14 14:06 ` Miroslav Benes
2016-04-19 10:16 ` [2/5] " Michael Ellerman
2016-04-13 12:53 ` [PATCH 3/5] powerpc/livepatch: Add livepatch header Michael Ellerman
2016-04-14 12:18 ` Miroslav Benes
2016-04-14 12:23 ` Miroslav Benes
2016-04-14 13:12 ` Michael Ellerman
2016-04-19 10:16 ` [3/5] " Michael Ellerman
2016-04-13 12:53 ` [PATCH 4/5] powerpc/livepatch: Add livepatch stack to struct thread_info Michael Ellerman
2016-04-19 10:16 ` [4/5] " Michael Ellerman
2016-04-13 12:53 ` [PATCH 5/5] powerpc/livepatch: Add live patching support on ppc64le Michael Ellerman
2016-04-19 10:16 ` [5/5] " Michael Ellerman
2016-04-13 13:01 ` [PATCH 0/5] Live patching for powerpc Miroslav Benes
2016-04-13 13:22 ` Jiri Kosina
2016-04-14 6:49 ` Michael Ellerman
2016-04-14 12:57 ` Torsten Duwe
2016-04-14 13:08 ` Michael Ellerman
2016-04-14 15:20 ` Torsten Duwe
2016-04-14 16:41 ` Josh Poimboeuf
2016-04-15 11:22 ` Michael Ellerman
2016-04-15 12:59 ` Josh Poimboeuf
2016-04-15 13:21 ` Michael Ellerman
2016-04-14 14:34 ` Jiri Kosina
2016-04-15 12:24 ` Michael Ellerman
2016-04-15 15:07 ` Jiri Kosina
2016-04-19 21:42 ` Balbir Singh
2016-04-19 21:52 ` Jiri Kosina
2016-04-13 18:22 ` Jessica Yu [this message]
2016-04-14 13:28 ` Miroslav Benes
2016-04-14 19:20 ` Jessica Yu
2016-04-15 8:28 ` Miroslav Benes
2016-04-15 10:01 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160413182228.GA16776@packer-debian-8-amd64.digitalocean.com \
--to=jeyu@redhat.com \
--cc=bsingharora@gmail.com \
--cc=duwe@lst.de \
--cc=jikos@kernel.org \
--cc=kamalesh@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=mpe@ellerman.id.au \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®