On Sun, 13 Jan 2019 23:33:56 +1100
Balbir Singh wrote:
> On Sat, Jan 12, 2019 at 02:45:41AM -0600, Segher Boessenkool wrote:
> > On Sat, Jan 12, 2019 at 12:09:14PM +1100, Balbir Singh wrote:
> > > Could you please define interesting frame on top a bit more?
> > > Usually the topmost return addres
On Wed, May 09, 2018 at 11:41:09AM +1000, Michael Ellerman wrote:
> Josh Poimboeuf writes:
>
> > Generally we refer to it as "the consistency model".
[...]
>
> We use "powerpc" as the prefix.
>
> So I've used:
>
> powerpc/livepatch: Implement reliable stack tracing for the consistency
> mod
On Mon, 7 May 2018 10:42:08 -0500
Josh Poimboeuf wrote:
> The subject doesn't actively describe what the patch does, maybe
> change it to something like:
>
> powerpc: Add support for HAVE_RELIABLE_STACKTRACE
>
> or maybe
>
> powerpc: Add support for livepatch consistency model
Maybe $SUBJ
c64le
that checks for the above conditions, where possible.
Signed-off-by: Torsten Duwe
Signed-off-by: Nicolai Stange
---
v3:
* big bunch of fixes, credits go to Nicolai Stange:
- get the correct return address from the graph tracer,
should it be active.
IMO this should be mov
On Thu, 8 Mar 2018 10:26:16 -0600
Josh Poimboeuf wrote:
> This doesn't seem to address some of my previous concerns:
You're right. That discussion quickly headed towards objtool
and I forgot about this one paragraph with the remarks.
> - Bailing on interrupt/exception frames
That is a good que
On Fri, 9 Mar 2018 08:43:33 +1100
Balbir Singh wrote:
> On Tue, 27 Feb 2018 17:09:24 +0100
> Torsten Duwe wrote:
> > +save_stack_trace_tsk_reliable(struct task_struct *tsk,
> > + struct stack_trace *trace)
>
> Just double checking
tch may be unneccessarily limited to ppc64le, but OTOH the only
user of this flag so far is livepatching, which is only implemented on
PPCs with 64-LE, a.k.a. ELF ABI v2.
This change also implements save_stack_trace_tsk_reliable() for ppc64
that checks for the above conditions, where possible.
Signed-off-by:
e successful
exit stricter, i.e. hit the initial stack value exactly instead of just
a window. Also, the check for kernel code looks clumsy IMHO. IOW:
Comments more than welcome!
Most of it is Copy&Waste, nonetheless:
Signed-off-by: Torsten Duwe
diff --git a/arch/powerpc/kernel/stacktrace.c
On Mon, Dec 18, 2017 at 12:56:22PM -0600, Josh Poimboeuf wrote:
> On Mon, Dec 18, 2017 at 03:33:34PM +1000, Nicholas Piggin wrote:
> > On Sun, 17 Dec 2017 20:58:54 -0600
> > Josh Poimboeuf wrote:
> >
> > > On Fri, Dec 15, 2017 at 07:40:09PM +1000, Nicholas Piggin wrote:
> > > > On Tue, 12 Dec 201
On Tue, Dec 12, 2017 at 01:12:37PM +0100, Miroslav Benes wrote:
>
> I think that this is not enough. You need to also implement
> save_stack_trace_tsk_reliable() for powerpc defined as __weak in
> kernel/stacktrace.c. See arch/x86/kernel/stacktrace.c for reference, but I
> think it would be muc
tch may be unneccessarily limited to ppc64le, but OTOH the only
user of this flag so far is livepatching, which is only implemented on
PPCs with 64-LE, a.k.a. ELF ABI v2.
Signed-off-by: Torsten Duwe
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c51e6ce42e7a..3e3a6ab2e089 100644
On Tue, Nov 07, 2017 at 07:34:29PM +1100, Michael Ellerman wrote:
> Josh Poimboeuf writes:
>
> > On Tue, Oct 31, 2017 at 07:39:59PM +0100, Torsten Duwe wrote:
> >> On Tue, Oct 31, 2017 at 09:53:16PM +0530, Naveen N . Rao wrote:
> >> > On 2017/
On Tue, Oct 31, 2017 at 09:53:16PM +0530, Naveen N . Rao wrote:
> On 2017/10/31 03:30PM, Torsten Duwe wrote:
> >
> > Maybe I failed to express my views properly; I find the whole approach
[...]
> > NAK'd-by: Torsten Duwe
>
> Hmm... that wasn't evident
I had asked questions previously because it
would have never come to my mind that someone would deliberately, without
a compelling reason, creates broken live patch modules and then tries
to fix them up with some ugly band-aid in the kernel. So for the record:
NAK'd-by: Torsten Duwe
Torsten
On Wed, Oct 18, 2017 at 11:47:35AM +0530, Kamalesh Babulal wrote:
>
> Consider a trivial patch, supplied to kpatch tool for generating a
> livepatch module:
>
> --- a/fs/proc/meminfo.c
> +++ b/fs/proc/meminfo.c
> @@ -132,7 +132,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
>
On Fri, Oct 06, 2017 at 11:27:42AM +0530, Kamalesh Babulal wrote:
>
> Consider the livepatch sequence[1]. Where function A calls B, B is the
> function which has been livepatched and the call to function B is
> redirected to patched version P. P calls the function C in M2, whereas
> C was local to
On Wed, Oct 04, 2017 at 11:25:16AM -0400, Kamalesh Babulal wrote:
>
> Both the failures with REL24 livepatch symbols relocation, can be
> resolved by constructing a new livepatch stub. The newly setup klp_stub
> mimics the functionality of entry_64.S::livepatch_handler introduced by
> commit 85baa
those embedded platforms.
> Signed-off-by: Hannes Reinecke
Reviewed-by: Torsten Duwe
> ---
> arch/powerpc/boot/Makefile | 7 ---
> arch/powerpc/boot/serial.c | 4
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/po
On Thu, Sep 01, 2016 at 09:56:42AM -0300, Mauricio Faria de Oliveira wrote:
> This patch introduces the 'iommu_alloc_quiet=driver_name' parameter
> to suppress the 'iommu_alloc failures' messages for that one driver.
>
> This is an additional approach for this 'problem' of flooding logs,
> not as
On Thu, Apr 14, 2016 at 11:08:02PM +1000, Michael Ellerman wrote:
> On Thu, 2016-04-14 at 14:57 +0200, Torsten Duwe wrote:
>
> > FTR: then I still have a few ppc64 hunks floating around to support certain
> > consistency
> > models...
>
> OK. I'm not quite s
On Thu, Apr 14, 2016 at 04:49:50PM +1000, Michael Ellerman wrote:
> On Wed, 2016-04-13 at 15:22 +0200, Jiri Kosina wrote:
> > On Wed, 13 Apr 2016, Miroslav Benes wrote:
> > > > This series adds live patching support for powerpc (ppc64le only ATM).
> > > >
> > > > It's unchanged since the version I
loc that area and realloc in
klp_arch_set_pc when it's full? Maybe along with a warning message?
That way a live patched kernel will not run into stack size problems
any earlier than an unpatched kernel would.
Just a thought.
Anyway, patch 5+6
Reviewed-by: Torsten Duwe
Torsten
___
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
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
ll need to be compiled
using the -fno-optimize-sibling-calls compiler flag!
Thanks go to Michael Matz and Richard Biener for reassurance about
heuristics and pointers to the compiler flag.
Signed-off-by: Torsten Duwe
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_
On Wed, Mar 16, 2016 at 09:23:19PM +1100, Michael Ellerman wrote:
>
> Sure. I'll try and get something working, though this merge window is not
> starting well so I may not get time for a few weeks :)
Do you already have something in mind?
Can you give us a hint?
Torsten
On Wed, Mar 09, 2016 at 05:59:40PM +1100, Balbir Singh wrote:
>
> Changelog v6:
> 1. Experimental changes -- need loads of testing
> Based on the assumption that very far TOC and LR values
> indicate the call happened through a stub and the
> stub return works diff
On Thu, Mar 17, 2016 at 10:58:42AM +1100, Balbir Singh wrote:
>
> To be honest I think my v6 works well, but I don't have complete confidence
> due to the lack of proper testing. livepatch samples plus some others I wrote
> and I one Petr wrote all work (calling patched from within patched),
I ha
On Thu, Mar 10, 2016 at 01:51:16PM +0100, Petr Mladek wrote:
> On Thu 2016-03-10 13:25:08, Petr Mladek wrote:
> > On Wed 2016-03-09 18:30:17, Torsten Duwe wrote:
> > > After the mini stack frame is no longer required for TOC storage, it can
> > > be eliminat
r0, LRSAVE(r0) /* get the real return address */
add r2, r2, r0 /* Add the current LR to offset */
Signed-off-by: Torsten Duwe
---
This is solution 1 now.
Do we really want that? I don't think so; this is merely to illustrate
what the alternative to klp_return_helper and
ller
will restore its TOC anyway from the ABI compliant location 24(r1)
right after return.
Signed-off-by: Torsten Duwe
---
This is only the preparation for dumping the mini stack frame.
It shouldn't break anything, bisecting-wise.
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/k
On Wed, Mar 09, 2016 at 05:10:25PM +0100, Petr Mladek wrote:
> On Tue 2016-03-08 16:34:35, Torsten Duwe wrote:
> > /* compile using "-ffixed-r14"! */
> > register unsigned long pass_TOC asm("r14");
>
> BTW: Is this reentrant, please? I mean, is it poss
On Wed, Mar 09, 2016 at 11:13:05AM +0100, Jiri Kosina wrote:
> On Wed, 9 Mar 2016, Torsten Duwe wrote:
> > was my first choice. Arguments on the stack? I thought we'll deal with them
> > once we get there (e.g. _really_ need to patch a varargs function or one
> > with a s
On Wed, Mar 09, 2016 at 10:44:23AM +0100, Petr Mladek wrote:
> find a solution that would work transparently. I mean that adding
> an extra hacks into selected functions in the patch might be quite
> error prone and problems hard to debug. I think that we all want this
> but I wanted to be sure :-)
On Wed, Mar 09, 2016 at 05:59:40PM +1100, Balbir Singh wrote:
>
> The previous revision was nacked by Torsten, but compared to the alternatives
I nacked it because I was confident it couldn't work. Same goes
for this one, sorry. My good intention was to save us all some work.
> @@ -1265,6 +1271,
On Wed, Mar 09, 2016 at 12:52:03AM +1100, Balbir Singh wrote:
>
> On 08/03/16 21:45, Torsten Duwe wrote:
> > To be fair, my last mail still was not 100% correct, but the conclusion
Wrote a correction to the correction. It should be clear now. Please nag me
if it isn't clear why
On Fri, Mar 04, 2016 at 08:22:22PM +0100, Torsten Duwe wrote:
> On Fri, Mar 04, 2016 at 07:16:57PM +0100, Torsten Duwe wrote:
> > On Fri, Mar 04, 2016 at 02:01:37PM +0100, Petr Mladek wrote:
> > >
> > > Do I understand it correctly that we could not patch functions t
std r0, LRSAVE(r1) /* save the real return address */
> + mtlrr0
> + blr
> +#endif
NAKed-by: Torsten Duwe
Torsten
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Fri, Mar 04, 2016 at 07:16:57PM +0100, Torsten Duwe wrote:
> On Fri, Mar 04, 2016 at 02:01:37PM +0100, Petr Mladek wrote:
> >
> > Do I understand it correctly that we could not patch functions that
> > pass arguments on the stack with this implementation? If yes, how har
On Fri, Mar 04, 2016 at 02:01:37PM +0100, Petr Mladek wrote:
>
> Do I understand it correctly that we could not patch functions that
> pass arguments on the stack with this implementation? If yes, how hard
> would be to get it working, please? At least, it would be great to
> catch this problem an
On Thu, Mar 03, 2016 at 05:52:01PM +0100, Petr Mladek wrote:
[...]
> index ec7f8aada697..2d5333c228f1 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -1265,6 +1271,31 @@ ftrace_call:
> ld r0, LRSAVE(r1)
> mtlrr0
>
> +#ifdef CONFIG_LIV
On Mon, Feb 29, 2016 at 08:26:23PM +1100, Michael Ellerman wrote:
[...]
> diff --git a/arch/powerpc/kernel/module_32.c b/arch/powerpc/kernel/module_32.c
> index 2c01665eb410..dd095496d225 100644
> --- a/arch/powerpc/kernel/module_32.c
> +++ b/arch/powerpc/kernel/module_32.c
> @@ -294,11 +294,19 @@
On Mon, Feb 29, 2016 at 08:26:22PM +1100, Michael Ellerman wrote:
> Move the logic to work out the kernel toc pointer into a header. This is
> a good cleanup, and also means we can use it elsewhere in future.
Yes, looks better, very nice.
> Signed-off-by: Michael Ellerman
Reviewed-by
On Thu, Feb 25, 2016 at 11:48:59AM +1100, Balbir Singh wrote:
> > @@ -608,6 +621,9 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
> > return -ENOENT;
> > if (!restore_r2((u32 *)location + 1, me))
> >
a bug when I wrote this test, Michael insisted
it was a feature :-)
> > +/bin/echo -e "#include \nnotrace int func() { return 0;
> > }" | \
> > +$* -S -x c -O2 -p -mprofile-kernel - -o - 2> /dev/null | \
> > +grep -q "mcount"
> > +
> > +notrace_r
the SPR loads to hopefully speed them up a bit.
> Also comment the asm much more, to hopefully make it clearer.
>
> Signed-off-by: Michael Ellerman
Reviewed-by: Torsten Duwe
Torsten
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.oz
o this anymore?
>
> Yes. Otherwise the code in apply_relocate_add() will see a far call with no
> nop
> slot after it to do the toc restore, and it considers that a bug (which it
> usually is, except mcount is special).
>
> As we discussed to
estore callee's TOC */
> > + ld r2, 24(r1)
> > +
> > addir1, r1, 112
> > mflrr0
> > std r0, LRSAVE(r1)
>
> Reviewed-by: Balbir Singh
Reviewed-by: Torsten Duwe
Torsten
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
)
return 1;
return 0;
leaves less freedom for the compiler to "optimise".
Signed-off-by: Torsten Duwe
Torsten
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
at runtime each time? It's a bit tricky to get the +- 0x8000 right
OTOH...
I wrote:
extern unsigned long __toc_start;
reladdr = addr - ((unsigned long)(&__toc_start) + 0x8000UL);
looks a bit odd, but evaluates to a constant for ftrace_caller.
Either way is fine with me:
Signed-o
practice.
The actual magic value is sort of debatable; it should be "improbable"
enough. But this can be changed easily, for each kernel compile, even.
> Signed-off-by: Michael Ellerman
Reviewed-by: Torsten Duwe
[for reference:]
>
> +#define STUB_MAGIC 0x737475
ce_caller() stub once,
> from module_finalize(). An additional benefit is we can clean the ifdefs
> up a little.
>
> Finally we must propagate the const'ness of some of the pointers passed
> to module_finalize(), but that is also an improvement.
>
>
On Wed, Feb 24, 2016 at 05:55:35PM +1100, Balbir Singh wrote:
>
>
> We need to remove the SQUASH_TOC_SAVE_INSNS bits as well, now that the
> ppc64_profile_stub_insns does not save r2
Sure -- this was meant to _replace_ the changes from patch 2/8, not on top.
And yes, it exposes duplicate defini
On Wed, Feb 17, 2016 at 02:08:41PM +1100, Michael Ellerman wrote:
>
> That stub uses r2 to find the location of itself, but it only works if r2
> holds
> the TOC for scsi_mod.ko. In this case r2 still contains ibmvscsi.ko's TOC.
Here's my solution, a bit rough still. This replaces the module_64.
On Wed, Feb 17, 2016 at 09:55:40PM +1100, Michael Ellerman wrote:
> On Wed, 2016-02-10 at 17:21 +0100, Torsten Duwe wrote:
>
> > --- a/arch/powerpc/kernel/module_64.c
> > +++ b/arch/powerpc/kernel/module_64.c
> > @@ -476,17 +474,44 @@ static unsigned long stub_for_addr(
On Tue, Feb 16, 2016 at 04:00:30PM +0530, Kamalesh Babulal wrote:
> * Torsten Duwe [2016-02-16 09:23:02]:
> >
> > N.b.: if you try to livepatch/trace such a leaf function without
> > global dependencies, it will crash if that function got called with
> > a different
On Tue, Feb 16, 2016 at 09:09:16PM +1100, Michael Ellerman wrote:
> On Mon, 2016-02-15 at 15:04 +0100, Torsten Duwe wrote:
> > If you use "-pg -mprofile-kernel", gcc seems to forget that, and omits the
> > TOC
> > load, for a similar assembler calling sequence.
On Tue, Feb 16, 2016 at 11:17:02AM +0530, Kamalesh Babulal wrote:
> * Petr Mladek [2016-02-12 17:45:17]:
> > int test(int a)
> > {
> > + printk("%d\n", a);
> > return ++a;
> > }
>
> Thanks. This workaround, helped to load sample livepatch module.
N.b.: if you try to livepatch/trace such
On Mon, Feb 15, 2016 at 03:04:08PM +0100, Torsten Duwe wrote:
> If you use "-pg -mprofile-kernel", gcc seems to forget that, and omits the TOC
> load, for a similar assembler calling sequence.
>
> Looking at the code I can _understand_ why this is so, but my GCC knowledge
&
On Mon, Feb 15, 2016 at 09:27:15PM +1100, Michael Ellerman wrote:
>
> There is explicit code in gcc to check whether the TOC setup is needed and
> only
That's undestood. The claim here is: that check is incomplete, at least.
> emit it when it's required. One case where it's *not* required is wh
On Thu, Feb 11, 2016 at 06:48:17PM +1100, Balbir Singh wrote:
> On Wed, 2016-02-10 at 17:25 +0100, Torsten Duwe wrote:
> > +
> > +echo "int func() { return 0; }" | \
> > +$* -S -x c -O2 -p -mprofile-kernel - -o - 2> /dev/null | \
> > +sed -n
On Thu, Feb 11, 2016 at 05:18:23PM +1100, Balbir Singh wrote:
>
> Quick question - I presume these apply on top of 4.5.0-rc2?
Yes.
Torsten
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-de
On Tue, Feb 02, 2016 at 04:46:27PM +0300, Denis Kirjanov wrote:
> > +
> > +#ifdef CONFIG_LIVEPATCH
> > +static inline int klp_check_compiler_support(void)
> > +{
> > +#if !defined(_CALL_ELF) || _CALL_ELF != 2 ||
> > !defined(CC_USING_MPROFILE_KERNEL)
> > + return 1;
> > +#endif
> > + return 0;
On Wed, Feb 10, 2016 at 12:50:38PM +1100, Michael Ellerman wrote:
> On Mon, 2016-01-25 at 16:31 +0100, Torsten Duwe wrote:
>
> > At least POWER7/8 have MMUs that don't completely autoload;
> > a normal, recoverable memory fault might pass through these functions.
> >
On Wed, Feb 10, 2016 at 11:33:33AM +1100, Michael Ellerman wrote:
> On Mon, 2016-01-25 at 16:31 +0100, Torsten Duwe wrote:
>
> > This patch complements the "notrace" attribute for selected functions.
> > It adds -mprofile-kernel to the cc flags to be stripped from t
regular expressions
to parse objdump output and is therefore much more tricky.
Signed-off-by: Petr Mladek
Signed-off-by: Torsten Duwe
---
arch/powerpc/Kconfig | 1 +
arch/s390/Kconfig | 1 +
kernel/livepatch/Makefile | 13 +
kernel/livepatch/core.c
Signed-off-by: Torsten Duwe
---
arch/powerpc/Kconfig | 3 +++
arch/powerpc/kernel/Makefile | 1 +
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e5f288c..8c7a327 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -160,6
fixup in arch/powerpc/kernel/entry_64.S
for local calls that are becoming global due to live patching.
And of course do the main KLP thing: return to a maybe different
address, possibly altered by the live patching ftrace op.
Signed-off-by: Torsten Duwe
---
arch/powerpc/include/asm
:
- remove -mprofile-kernel from low level, boot code and
code-patching objects' CFLAGS.
Signed-off-by: Torsten Duwe
---
arch/powerpc/kernel/Makefile | 12 ++--
arch/powerpc/lib/Makefile| 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/po
ut on compile with HAVE_DYNAMIC_FTRACE_WITH_REGS
and a buggy compiler.
* arch/powerpc/Kconfig / kernel/trace/Kconfig:
- declare that ppc64le HAVE_MPROFILE_KERNEL and
HAVE_DYNAMIC_FTRACE_WITH_REGS, and use it.
Signed-off-by: Torsten Duwe
---
arch/powerpc/Kc
ff-by: Torsten Duwe
---
arch/powerpc/kernel/ftrace.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 1fad1b3..ef8b916 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftr
. This trampoline jump happens from
a function prologue before a new stack frame is set up, so bad
things may happen otherwise...
- relax is_module_trampoline() to recognise the modified
trampoline.
Signed-off-by: Torsten Duwe
---
arch/powerpc/include/asm/ftrace.h | 5 +++
arch
mon macros to make things readable.
- pull the R2 stack location definition from
arch/powerpc/kernel/module_64.c
* arch/powerpc/kernel/module_64.c:
- enhance binary code examination to handle the new patterns.
Signed-off-by: Torsten Duwe
---
arch/powerpc/include/asm/code-patchin
turned out the stack frame it tried to manipulate does not
exist at that point.
* changes only needed in order to support -mprofile-kernel are now
in a separate patch, prepended.
* Kconfig cleanup so this is only selectable on ppc64le.
Petr Mladek (1):
livepatch: Detect offset for
On Mon, Feb 08, 2016 at 10:49:28AM -0500, Steven Rostedt wrote:
> On Mon, 8 Feb 2016 16:23:06 +0100
> Petr Mladek wrote:
>
> > >From 2b0fcb678d7720d03f9c9f233b61ed9ed4d420b3 Mon Sep 17 00:00:00 2001
> > From: Petr Mladek
> > Date: Mon, 8 Feb 2016 16:03:03 +0100
> > Subject: [PATCH] ftrace: All
On Mon, Feb 08, 2016 at 11:34:06AM +0100, Petr Mladek wrote:
> On Sat 2016-02-06 11:32:43, Torsten Duwe wrote:
> > On Fri, Feb 05, 2016 at 05:18:34PM +0100, Petr Mladek wrote:
> > [...]
> > > more complicated. Whem I think about it, the change below does similar
On Fri, Feb 05, 2016 at 05:18:34PM +0100, Petr Mladek wrote:
[...]
> more complicated. Whem I think about it, the change below does similar
> job and looks more strightforwad:
Had I only looked closer. That's exactly how I thought it would work
in the first place. I'd call that a fix. Full ACK fro
Signed-off-by: Torsten Duwe
---
arch/powerpc/Kconfig | 3 +++
arch/powerpc/kernel/Makefile | 1 +
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e5f288c..8c7a327 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -160,6
fixup in arch/powerpc/kernel/entry_64.S
for local calls that are becoming global due to live patching.
And of course do the main KLP thing: return to a maybe different
address, possibly altered by the live patching ftrace op.
Signed-off-by: Torsten Duwe
---
arch/powerpc/include/asm
This patch complements the "notrace" attribute for selected functions.
It adds -mprofile-kernel to the cc flags to be stripped from the command
line for code-patching.o and feature-fixups.o, in addition to "-pg"
Signed-off-by: Torsten Duwe
---
arch/powerpc/lib/Makefile | 4
At least POWER7/8 have MMUs that don't completely autoload;
a normal, recoverable memory fault might pass through these functions.
If a dynamic tracer function causes such a fault, any of these functions
being traced with -mprofile-kernel may cause an endless recursion.
Signed-off-by: To
level and boot code objects'
CFLAGS for FUNCTION_TRACER configurations.
Signed-off-by: Torsten Duwe
---
arch/powerpc/kernel/Makefile | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 79
with HAVE_DYNAMIC_FTRACE_WITH_REGS
and a buggy compiler.
* arch/powerpc/Kconfig / kernel/trace/Kconfig:
- declare that ppc64le HAVE_MPROFILE_KERNEL and
HAVE_DYNAMIC_FTRACE_WITH_REGS, and use it.
Signed-off-by: Torsten Duwe
---
arch/powerpc/Kconfig| 2 ++
ff-by: Torsten Duwe
---
arch/powerpc/kernel/ftrace.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 1fad1b3..ef8b916 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftr
. This trampoline jump happens from
a function prologue before a new stack frame is set up, so bad
things may happen otherwise...
- relax is_module_trampoline() to recognise the modified
trampoline.
Signed-off-by: Torsten Duwe
---
arch/powerpc/include/asm/ftrace.h | 5 +++
arch
mon macros to make things readable.
- pull the R2 stack location definition from
arch/powerpc/kernel/module_64.c
* arch/powerpc/kernel/module_64.c:
- enhance binary code examination to handle the new patterns.
Signed-off-by: Torsten Duwe
---
arch/powerpc/include/asm/code-patchin
patch, prepended.
* Kconfig cleanup so this is only selectable on ppc64le.
Petr Mladek (1):
livepatch: Detect offset for the ftrace location during build
Torsten Duwe (9):
ppc64 (le): prepare for -mprofile-kernel
ppc64le FTRACE_WITH_REGS implementation
ppc use ftrace_modify_all_code de
On Wed, Feb 03, 2016 at 09:55:11AM +0100, Jiri Kosina wrote:
> On Wed, 3 Feb 2016, AKASHI Takahiro wrote:
> > those efforts, we are proposing[1] a new *generic* gcc option,
> > -fprolog-add=N.
> > This option will insert N nop instructions at the beginning of each
> > function.
> The interesting
On Tue, Feb 02, 2016 at 01:12:24PM +0100, Petr Mladek wrote:
>
> Hmm, the size of the offset is not a constant. In particular, leaf
> functions do not set TOC before the mcount location.
To be slightly more precise, a leaf function that additionally uses
no global data. No global function calls,
On Thu, Jan 28, 2016 at 03:26:59PM +1100, Michael Ellerman wrote:
>
> That raises an interesting question, how does it work *without*
> DYNAMIC_FTRACE?
>
> It looks like you haven't updated that version of _mcount at all? Or maybe I'm
> missing an #ifdef somewhere?
You didn't, I did. I haven't
On Thu, Jan 28, 2016 at 02:31:58PM +1100, Michael Ellerman wrote:
>
> Looking at GCC history it looks like the fix is in 4.9.0 and anything later.
Good. But 4.8.5 has a buggy -mprofile-kernel, and there will be no 4.8.6, Bad.
> But a version check doesn't work with patched distro/vendor toolchai
On Wed, Jan 27, 2016 at 11:28:09PM +1030, Alan Modra wrote:
> On Wed, Jan 27, 2016 at 09:19:27PM +1100, Michael Ellerman wrote:
> >
> > Can we use r11 instead? eg:
> >
> > _GLOBAL(_mcount)
> > mflrr11
> > mtctr r11
> > mtlrr0
> > bctr
>
> Depends on what you need to sup
On Wed, Jan 27, 2016 at 09:51:12PM +1100, Balbir Singh wrote:
> On Mon, 25 Jan 2016 16:38:48 +0100
> Torsten Duwe wrote:
>
> > Changes since v5:
> > * extra "std r0,LRSAVE(r1)" for gcc-6
> > This makes the code compiler-agnostic.
> >
On Wed, Jan 27, 2016 at 09:19:27PM +1100, Michael Ellerman wrote:
> Hi Torsten,
>
> > +++ b/arch/powerpc/kernel/entry_64.S
> > @@ -1206,7 +1206,12 @@ _GLOBAL(enter_prom)
> > #ifdef CONFIG_DYNAMIC_FTRACE
> > _GLOBAL(mcount)
> > _GLOBAL(_mcount)
> > - blr
> > + std r0,LRSAVE(r1) /* gcc6 d
On Tue, Jan 26, 2016 at 11:50:25AM +0100, Miroslav Benes wrote:
> > + */
> > +int klp_write_module_reloc(struct module *mod, unsigned long type,
> > + unsigned long loc, unsigned long value)
> > +{
> > + /* This requires infrastructure changes; we need the loadinfos. */
> >
On Tue, Jan 26, 2016 at 01:48:53PM +0100, Petr Mladek wrote:
> On Tue 2016-01-26 11:50:25, Miroslav Benes wrote:
> >
> > We still need Petr's patch from [1] to make livepatch work, right? Could
> > you, please, add it to this patch set to make it self-sufficient?
It's Petr's patch, I don't want
At least POWER7/8 have MMUs that don't completely autoload;
a normal, recoverable memory fault might pass through these functions.
If a dynamic tracer function causes such a fault, any of these functions
being traced with -mprofile-kernel may cause an endless recursion.
Signed-off-by: To
level and boot code objects'
CFLAGS for FUNCTION_TRACER configurations.
Signed-off-by: Torsten Duwe
---
arch/powerpc/kernel/Makefile | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index ba
Signed-off-by: Torsten Duwe
---
arch/powerpc/Kconfig |3 +++
arch/powerpc/kernel/Makefile |1 +
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 89b1a2a..62a3f54 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -162,6
fixup in arch/powerpc/kernel/entry_64.S
for local calls that are becoming global due to live patching.
And of course do the main KLP thing: return to a maybe different
address, possibly altered by the live patching ftrace op.
Signed-off-by: Torsten Duwe
---
arch/powerpc/include/asm
1 - 100 of 200 matches
Mail list logo
