> -Original Message-
> From: Scott Wood
> Sent: Saturday, March 19, 2016 2:16 AM
> To: Rob Herring; Yangbo Lu
> Cc: devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> c...@vger.kernel.org; linux-...@vger.
> -Original Message-
> From: Scott Wood
> Sent: Saturday, March 19, 2016 2:28 AM
> To: Arnd Bergmann; Rob Herring
> Cc: Yangbo Lu; linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org;
> ulf.hans...@linaro.org; Zhao Qiang; Russell King; Bhupesh Sharma;
> net...@vger.kernel.org; Joerg R
On Thu, Mar 24, 2016 at 01:58:13PM +0100, Jiri Slaby wrote:
> We need to call exit_thread from copy_process in a fail path. So make
> it accept task_struct as a parameter.
Hmm, so what this means is that exit_thread() can now be called for
threads which are not running on the CPU. So, I think th
On Thu, Mar 24, 2016 at 01:58:13PM +0100, Jiri Slaby wrote:
> void
> -exit_thread(void)
> +exit_thread(struct task_struct *me)
> {
> }
task_struct arguments are called: tsk, task, p
'me' seems very wrong, as that could only mean 'current', and its
clearly not that.
_
On 03/24/2016, 02:03 PM, Peter Zijlstra wrote:
> On Thu, Mar 24, 2016 at 01:58:13PM +0100, Jiri Slaby wrote:
>> void
>> -exit_thread(void)
>> +exit_thread(struct task_struct *me)
>> {
>> }
>
> task_struct arguments are called: tsk, task, p
> 'me' seems very wrong, as that could only mean 'curre
We need to call exit_thread from copy_process in a fail path. So make
it accept task_struct as a parameter.
Signed-off-by: Jiri Slaby
Cc: Richard Henderson
Cc: Ivan Kokshaysky
Cc: Matt Turner
Cc: Vineet Gupta
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Haavard Skinnemoen
Cc:
Acked-by: Ian Munsie
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Acked-by: Ian Munsie
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Fixes the following testsuite failure:
$ sudo ./perf test -v kallsyms
1: vmlinux symtab matches kallsyms :
--- start ---
test child forked, pid 12489
Using /proc/kcore for kernel object code
Looking at the vmlinux_path (8 entries long)
Using /boot/vmlinux for symbols
0xc0
* Michael Ellerman [2016-03-24 22:04:00]:
> Not for merging.
>
Hi Michael,
Loading the livepatch sample module, trigger following warning
Mar 24 21:44:59 ubuntu kernel: [ 40.467580] sysfs: cannot create duplicate
filename '/kernel/livepatch/livepatch_sample/vmlinux'
Mar 24 21:44:59 ubuntu
* Torsten Duwe [2016-03-24 11:27:57]:
> On Thu, Mar 24, 2016 at 03:44:55PM +0530, Kamalesh Babulal wrote:
> > * Torsten Duwe [2016-03-23 16:58:58]:
> >
> > >
> > > Since nobody liked the extra stack frame nor its workarounds, here is
> > > the next attempt. Assumptions:
> > >
> > > 1. Heurist
On Thu, 24 Mar 2016, Steven Rostedt wrote:
> > In order to support live patching on powerpc we would like to call
> > ftrace_location_range(), so make it global.
>
> Do you want me to try to get this into this merge window?
I don't think that's necessary. The dependency (rest of livepatching bit
On Thu, 24 Mar 2016 22:04:01 +1100
Michael Ellerman wrote:
> In order to support live patching on powerpc we would like to call
> ftrace_location_range(), so make it global.
Do you want me to try to get this into this merge window?
-- Steve
___
Linuxp
On Thu, Mar 24, 2016 at 10:04:05PM +1100, Michael Ellerman wrote:
> +livepatch_handler:
> + CURRENT_THREAD_INFO(r12, r1)
[...]
> + /* Put ctr in r12 for global entry and branch there */
> + mfctr r12
> + bctrl
^
I like this piece. No need to fiddle out the return helpe
On Thu, 2016-03-24 at 09:04 +0100, Torsten Duwe wrote:
> On Thu, Mar 24, 2016 at 01:23:01PM +1100, Balbir Singh wrote:
> > On 24/03/16 02:58, Torsten Duwe wrote:
> > >
> > > 1. Heuristics are bad. The better they are, the more subtly the
> > >way they might fail.
> [...]
>
> This CR+4 code l
Add the kconfig logic & assembly support for handling live patched
functions. This depends on DYNAMIC_FTRACE_WITH_REGS, which in turn
depends on the new -mprofile-kernel ftrace ABI, which is only supported
currently on ppc64le.
Live patching is handled by a special ftrace handler. This means it ru
In order to support live patching we need to maintain an alternate
stack of TOC & LR values. We use the base of the stack for this, and
store the "live patch stack pointer" in struct thread_info.
Unlike the other fields of thread_info, we can not statically initialise
that value, so it must be don
Add the powerpc specific livepatch definitions. In particular we provide
a non-default implementation of klp_get_ftrace_location().
This is required because the location of the mcount call is not constant
when using -mprofile-kernel (which we always do for live patching).
Signed-off-by: Torsten D
When livepatch tries to patch a function it takes the function address
and asks ftrace to install the livepatch handler at that location.
ftrace will look for an mcount call site at that exact address.
On powerpc the mcount location is not the first instruction of the
function, and in fact it's no
In order to support live patching on powerpc we would like to call
ftrace_location_range(), so make it global.
Signed-off-by: Torsten Duwe
Signed-off-by: Balbir Singh
Signed-off-by: Michael Ellerman
---
include/linux/ftrace.h | 1 +
kernel/trace/ftrace.c | 14 +-
2 files changed,
Not for merging.
---
arch/powerpc/kernel/setup_64.c | 26 +++
samples/livepatch/livepatch-sample.c | 90 ++--
2 files changed, 113 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index f98be8
On Thu, Mar 24, 2016 at 03:44:55PM +0530, Kamalesh Babulal wrote:
> * Torsten Duwe [2016-03-23 16:58:58]:
>
> >
> > Since nobody liked the extra stack frame nor its workarounds, here is
> > the next attempt. Assumptions:
> >
> > 1. Heuristics are bad. The better they are, the more subtly the
>
* Torsten Duwe [2016-03-23 16:58:58]:
>
> Since nobody liked the extra stack frame nor its workarounds, here is
> the next attempt. Assumptions:
>
> 1. Heuristics are bad. The better they are, the more subtly the
>way they might fail.
>
> 2. The TOC pointer is usually dividable by 4, if no
On Wed, 2016-03-23 at 16:47 +1100, Cyril Bur wrote:
> Currently start_thread() doesn't sanitise TAR.
>
> The TAR SPR register is a register that can be set and branched to, not
> sanitising it presents an information leak to the new executable.
>
> Other SPR registers such as the Performance regi
On Thu, Mar 24, 2016 at 01:23:01PM +1100, Balbir Singh wrote:
> On 24/03/16 02:58, Torsten Duwe wrote:
> >
> > 1. Heuristics are bad. The better they are, the more subtly the
> >way they might fail.
[...]
> I missed this yesterday, not on cc, but caught it on the list today
I replied to Michae
25 matches
Mail list logo
