d to
> include this or we always get the non jump label fallback code.
>
> Fixes: 1bc9e47aa8e4 ("powerpc/jump_label: Use HAVE_JUMP_LABEL")
> Signed-off-by: Anton Blanchard
Acked-by: Steven Rostedt
-- Steve
___
Linuxppc-dev m
t;
> diff --git a/arch/arm/include/asm/jump_label.h
> b/arch/arm/include/asm/jump_label.h
Acked-by: Steven Rostedt
-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
e also need to add -DCC_HAVE_ASM_GOTO to KBUILD_AFLAGS.
>
> Signed-off-by: Anton Blanchard
Acked-by: Steven Rostedt
-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Tue, 21 Apr 2015 16:33:36 +0530
"Naveen N. Rao" wrote:
> Add a new powerpc-specific trace clock using the timebase register,
> similar to x86-tsc. This gives us a fast, monotonic, cross-cpu clock
> for trace entries and can be used to correlate events across cpus as
> well as across hypervisor
On Thu, 23 Apr 2015 12:15:04 +0530
"Naveen N. Rao" wrote:
> diff --git a/arch/powerpc/include/asm/trace_clock.h
> b/arch/powerpc/include/asm/trace_clock.h
> new file mode 100644
> index 000..0b0d094
> --- /dev/null
> +++ b/arch/powerpc/include/asm/trace_clock.h
> @@ -0,0 +1,27 @@
> +/*
> + *
events across cpus as well as across
> hypervisor and guests.
>
> Signed-off-by: Naveen N. Rao
> ---
> Changes since v1:
> - removed unnecessary #ifdef in trace_clock.h
> - changed config build dependency for trace_clock.o from TRACE_CLOCK to
> TRACING
>
Looks
I'm running my ftrace tests on my PAsemi box with your patches and
things are not going so well.
Just this patch alone causes my first stress test to lock up, and
things don't go so well after that.
INFO: rcu_sched detected stalls on CPUs/tasks: {} (detected by 1, t=5253
jiffies, g=3603, c=3602,
On Wed, 17 Sep 2014 17:07:03 +1000
Anton Blanchard wrote:
> mod_return_to_handler is the same as return_to_handler, except
> it handles the change of the TOC (r2). Add this into
> return_to_handler and remove mod_return_to_handler.
Adding this patch actually gave me some more output. Funny that?
On Wed, 17 Sep 2014 17:07:04 +1000
Anton Blanchard wrote:
> Instead of passing in the stack address of the link register
> to be modified, just pass in the old value and return the
> new value and rely on ftrace_graph_caller to do the
> modification.
>
> This removes the exception handling aroun
On Tue, 23 Sep 2014 19:46:04 -0400
Steven Rostedt wrote:
> This could be broken from the earlier patches, I haven't run just this
> test. I probably should on them.
I went back and tested, and it breaks under the first patch.
-- Steve
_
On Wed, 24 Sep 2014 12:33:07 +1000
Anton Blanchard wrote:
> Hi Ben,
>
> > > I'll drop that patch and respin.
> >
> > Or maybe do a toolchain check / or enable it in LE ?
>
> We are scratching our heads trying to remember details of the issue
> right now. In retrospect we should have linked the
On Mon, 8 Dec 2014 14:27:01 +1100
Anton Blanchard wrote:
> I have a busy ppc64le KVM box where guests sometimes hit the infamous
> "kernel BUG at kernel/smpboot.c:134!" issue during boot:
>
> BUG_ON(td->cpu != smp_processor_id());
>
> Basically a per CPU hotplug thread scheduled on the wrong C
On Tue, Jan 06, 2015 at 09:20:27PM +1100, Anton Blanchard wrote:
> To use jump labels in assembly we need the HAVE_JUMP_LABEL define,
> so we select a fallback version if the toolchain does not support
> them.
>
> Modify linux/jump_label.h so it can be included by assembly files.
> We also need to
On Sun, 2013-05-19 at 12:35 +0300, Michael S. Tsirkin wrote:
> No, I was not assuming that. What I'm trying to say is that a caller
> that does something like this under a spinlock:
> preempt_disable
> pagefault_disable
> error = copy_to_user
> pagefault_enable
> pree
On Sun, 2013-05-19 at 16:34 +0300, Michael S. Tsirkin wrote:
> Right but we need to keep it working on upstream as well.
> If I do preempt_enable under a spinlock upstream won't it
> try to sleep under spinlock?
No it wont. A spinlock calls preempt_disable implicitly, and a
preempt_enable() will
On Sun, 2013-05-19 at 19:40 +0300, Michael S. Tsirkin wrote:
> OK I get it. So let me correct myself. The simple code
> that does something like this under a spinlock:
> > preempt_disable
> > pagefault_disable
> > error = copy_to_user
> > pagefault_enable
> > preempt_
On Thu, 2013-06-13 at 21:04 +1000, Michael Ellerman wrote:
> Although that should be sufficient to fix the bug, we also mark the
> runlatch routines as notrace. They are called very early in the
> exception entry and we are asking for trouble tracing them. They are
> also fairly uninteresting and
On Fri, 2013-06-14 at 00:31 +1000, Michael Ellerman wrote:
> On Thu, 2013-06-13 at 08:45 -0400, Steven Rostedt wrote:
> > On Thu, 2013-06-13 at 21:04 +1000, Michael Ellerman wrote:
> >
> > > Although that should be sufficient to fix the bug, we also mark the
> >
On Fri, 2013-06-14 at 14:46 +0200, Rojhalat Ibrahim wrote:
> On Friday 14 June 2013 05:28:00 Paul E. McKenney wrote:
> > On Fri, Jun 14, 2013 at 01:47:00PM +0200, Rojhalat Ibrahim wrote:
> > > Hi,
> > >
> > > the current mainline kernel from git reproducibly hangs on my Freescale
> > > PowerPC P50
On Sat, 2013-06-15 at 12:02 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-14 at 17:06 -0400, Steven Rostedt wrote:
> > I was pretty much able to reproduce this on my PA Semi PPC box. Funny
> > thing is, when I type on the console, it makes progress. Anyway, it
> > s
On Sat, 2013-06-15 at 12:21 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-14 at 22:17 -0400, Steven Rostedt wrote:
> > On Sat, 2013-06-15 at 12:02 +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2013-06-14 at 17:06 -0400, Steven Rostedt wrote:
> > >
On Mon, 2013-06-17 at 15:21 +0200, Rojhalat Ibrahim wrote:
> On Friday 14 June 2013 22:17:34 Steven Rostedt wrote:
> > On Sat, 2013-06-15 at 12:02 +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2013-06-14 at 17:06 -0400, Steven Rostedt wrote:
> > > > I was pretty
we synchronize with CPU hotplug, instead of combining it subtly with
> disabling preemption).
>
> In future, when actually removing stop_machine(), we will alter the
> implementation of these APIs to a suitable synchronization scheme.
>
> Cc: Thomas Gleixner
> Cc: Andrew Morton
On Sun, 2013-06-23 at 19:08 +0530, Srivatsa S. Bhat wrote:
Just to make the code a little cleaner, can you add:
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 860f51a..e90d9d7 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -63,6 +63,72 @@ static struct {
> .refcount = 0,
> };
>
On Wed, 2013-06-26 at 07:34 -0700, Paul E. McKenney wrote:
> On Wed, Jun 26, 2013 at 03:29:40PM +0100, David Laight wrote:
> > > Once stop_machine() is gone from the CPU offline path, we won't be able
> > > to depend on disabling preemption to prevent CPUs from going offline
> > > from under us.
>
On Wed, 2013-06-26 at 08:21 -0700, Tejun Heo wrote:
> On Wed, Jun 26, 2013 at 10:51:11AM -0400, Steven Rostedt wrote:
> > > It would also increase the latency of CPU-hotunplug operations.
> >
> > Is that a big deal?
>
> I thought that was the whole deal w
On Wed, 2013-07-10 at 00:00 +0200, Alexander Graf wrote:
> Then don't overflow the buffer. Make it large enough. IIRC ftrace improved
> recently to dynamically increase the buffer size too.
>
> Steven, do I remember correctly here?
Not really. Ftrace only dynamically increases the buffer when t
On Tue, 2013-07-09 at 17:26 -0500, Scott Wood wrote:
> On 07/09/2013 05:00:26 PM, Alexander Graf wrote:
> >
> > On 09.07.2013, at 23:54, Scott Wood wrote:
> >
> > > On 07/09/2013 04:49:32 PM, Alexander Graf wrote:
> > >> Not sure I understand. What the timing stats do is that they
> > measure t
Why are your patches all as replies?
On Wed, 3 Jun 2015 15:08:29 +0200
Torsten Duwe wrote:
> Implement ftrace on ppc64
What do you mean "Implement ftrace on ppc64"? It's already implemented.
I'm not even going to bother looking at this patch because I have no
idea what its purpose is.
-- Ste
On Thu, 18 Jun 2015 18:21:07 +0200
Torsten Duwe wrote:
> +
> _GLOBAL(ftrace_stub)
> + nop
> + nop
> +.localentry ftrace_stub,.-ftrace_stub
You might want to run checkpatch and fix your whitespace errors.
-- Steve
> blr
> #else
> _GLOBAL_TOC(_mcount)
> @@ -1211,12
On Thu, 18 Jun 2015 18:17:27 +0200
Torsten Duwe wrote:
> Did I miss anything else? I have the notrace optimisations and
> kernel live patching in the queue, which depends on this, so I'd
> really appreciate a comment whether it is acceptable in this form
> or not. Thanks in advance!
>
> To
On Fri, 19 Jun 2015 14:00:44 +0200
Torsten Duwe wrote:
> | kernel/bounds.c:1:0: error: -mcall-aixdesc incompatible with -mabi=elfv2
>
> Are you building ppc64, little endian, ELF ABIv2 ?
It's big endian.
> Is your cross compiler working properly?
Well, just before applying your patches, I bu
On Fri, 19 Jun 2015 14:17:03 +0200
Torsten Duwe wrote:
> On Fri, Jun 19, 2015 at 10:15:44AM +0300, Denis Kirjanov wrote:
> >
> > Hi Torsten,
> >
> > could you provide a description how you did test that.
>
> Vanilla kernel, those patches on top, built as described to
> Steven in the previous m
112
+++---
arch/powerpc/kernel/ftrace.c | 67 --
arch/powerpc/kernel/module_64.c | 33 ++-
4 files changed, 186 insertions(+), 31 deletions(-)
--
Signed-off-by: Steven Rostedt
-- Steve
On Thu, 17 Oct 2013 12:10:28 +0200
Radim Krčmář wrote:
> We implemented the optimized branch selection in higher levels of api.
> That made static_keys very unintuitive, so this patch introduces another
> element to jump_table, carrying one bit that tells the underlying code
> which branch to opt
t a good idea.
As it seems that the exit handler is required in case of error at boot
up, it doesn't make sense to allow it to unmap the region after the
system is running.
Cc: Olof Johansson
Signed-off-by: Steven Rostedt
diff --git a/arch/powerpc/platforms/pasemi/cpufreq.c
b/arch/pow
On Tue, 2013-01-22 at 13:03 +0530, Srivatsa S. Bhat wrote:
> A straight-forward (and obvious) algorithm to implement Per-CPU Reader-Writer
> locks can also lead to too many deadlock possibilities which can make it very
> hard/impossible to use. This is explained in the example below, which helps
>
On Wed, 2013-01-23 at 01:28 +0530, Srivatsa S. Bhat wrote:
> > I thought global locks are now fair. That is, a reader will block if a
> > writer is waiting. Hence, the above should deadlock on the current
> > rwlock_t types.
> >
>
> Oh is it? Last I checked, lockdep didn't complain about this AB
On Mon, 2013-02-18 at 11:58 +0100, Vincent Guittot wrote:
> My tests have been done without cpuidle because i have some issues
> with function tracer and cpuidle
>
> But the cpu hotplug and cpuidle work well when I run the tests without
> enabling the function tracer
>
I know suspend and resume
On Mon, 2013-02-18 at 21:51 +0530, Srivatsa S. Bhat wrote:
> Hi Michel,
> Yes.. I don't think we can avoid that. Moreover, since we _want_ unfair
> reader/writer semantics to allow flexible locking rules and guarantee
> deadlock-safety, having a recursive reader side is not even an issue, IMHO.
R
On Mon, 2013-02-18 at 17:50 +0100, Vincent Guittot wrote:
> yes for sure.
> The problem is more linked to cpuidle and function tracer.
>
> cpu hotplug and function tracer work when cpuidle is disable.
> cpu hotplug and cpuidle works if i don't enable function tracer.
> my platform is dead as soon
On Mon, 2013-02-18 at 17:50 +0100, Vincent Guittot wrote:
> yes for sure.
> The problem is more linked to cpuidle and function tracer.
>
> cpu hotplug and function tracer work when cpuidle is disable.
> cpu hotplug and cpuidle works if i don't enable function tracer.
> my platform is dead as soon
()
Now there are no users of _INIT_GLOBAL(), _STATIC() and
_INIT_STATIC() we can remove them.
My box builds and boots again.
Signed-off-by: Steven Rostedt
---
diff --git a/arch/powerpc/include/asm/ppc_asm.h
b/arch/powerpc/include/asm/ppc_asm.h
index 9ea266e..1baf197 100644
---
On Tue, 15 Jul 2014 12:05:55 +1000
Benjamin Herrenschmidt wrote:
> On Mon, 2014-07-14 at 20:12 -0400, Steven Rostedt wrote:
> > I wanted to test some new ftrace code on my PASemi electra powerpc box.
> > But unfortunately it failed to build. It failed with this:
> >
>
On Tue, 15 Jul 2014 12:05:55 +1000
Benjamin Herrenschmidt wrote:
> Cheers,
> Ben.
>
While I got your attention, could you please ack my patch with subject:
[RFA][PATCH 09/27] powerpc/ftrace: Add call to ftrace_graph_is_dead() in
function graph code
so that I can push it through my tree.
Th
A bug in ftrace was reported to me that affects ARM and ARM64 but not
x86. Looking at the code it appears to affect PowerPC as well. So I
booted up my old PA Semi, to give it a try. The last time I booted it
was for a 3.17 kernel. Unfortunately, for 4.0-rc2 it crashed with:
Unable to handle kerne
On Fri, 06 Mar 2015 15:18:42 +1100
Benjamin Herrenschmidt wrote:
> Can you shoot me the DT (/proc/device-tree in a tarball) ?
Attached.
-- Steve
device-tree.tar.bz2
Description: application/bzip
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.oz
On Sat, 07 Mar 2015 09:56:22 +1100
Benjamin Herrenschmidt wrote:
> In the meantime, try that patch:
>
It boots for me.
Tested-by: Steven Rostedt
-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozla
On Tue, 10 Mar 2015 11:28:03 +1100
Michael Ellerman wrote:
>
> Mine is running:
>
> CFE version PAS-2.0.29 for ATHENA (64bit,MP,BE,PPC)
> Build Date: Mon Jun 30 11:47:25 PDT 2008 (mpl@mitch-1)
>
> Steve is your CFE older than that?
Seems so:
CFE version PAS-2.0.20 for ELECTRA (64bit,MP,B
On Thu, 12 Mar 2015 14:49:52 +1100
Michael Ellerman wrote:
>
> >From Documentation/kasan.txt:
>
> therefore you will need a certain version of GCC > 4.9.2
>
> AFAIK gcc 4.9.3 hasn't been released yet. (Or does it mean >= 4.9.2 ?)
It means 4.9.2. I also feel that this makes it too premature
On Tue, 08 Mar 2016 10:20:22 +1100
Michael Ellerman wrote:
> >
> > There is one remaining issue which I think would be really nice to
> > have(TM), and that's Steven's Ack for the whole thing :)
>
> Yeah. He's been on CC the whole time, but he's probably getting a bit sick of
> it all, as we'r
ivepatch.h| 2 ++
> kernel/livepatch/core.c | 28 +++++---
> kernel/trace/ftrace.c| 14 +-
For the changes to the ftrace files, add my:
Acked-by: Steven Rostedt
You can take the rest.
-- Steve
> 9 files changed, 171 insertions(+)
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 Wed, 13 Apr 2016 21:39 -0300
Thiago Jung Bauermann wrote:
> People seem to be considering patches for next, so this looks like a good
> moment to ping about this one.
Your timing is fine with respect to the merge window. I'm currently
traveling, but I'll get to it on Monday. I have it marke
On Thu, 14 Apr 2016 17:11:35 +1000
Michael Ellerman wrote:
> >
> > diff --git a/arch/powerpc/include/asm/ftrace.h
> > b/arch/powerpc/include/asm/ftrace.h
> > index 50ca7585abe2..68f1858796c6 100644
> > --- a/arch/powerpc/include/asm/ftrace.h
> > +++ b/arch/powerpc/include/asm/ftrace.h
> > @@ -58
> # cat available_filter_functions | grep _do_fork
> ._do_fork
>
> This change introduces no regressions on the perf and ftracetest
> testsuite results.
>
> Cc: Steven Rostedt
> Cc: Ingo Molnar
> Cc: Michael Ellerman
> Cc: linuxppc-dev@lists.ozlabs.org
&g
On Wed, 16 Sep 2015 22:01:06 +0200 (CEST)
Thomas Gleixner wrote:
> On Wed, 16 Sep 2015, Scott Wood wrote:
>
> > On Wed, 2015-09-16 at 18:23 +0200, Thomas Gleixner wrote:
> > > With this commit applied, my MPC5200 board fails to boot 4.3-rc1. The
> > > boot failure is silent.
> > >
> > > Bisecti
On Thu, 17 Sep 2015 12:13:15 +0200 (CEST)
Thomas Gleixner wrote:
> Digging deeper. My assumption that it's a post powerpc merge failure
> turned out to be wrong.
Does 4.2 have the problem?
>
> Some more data points. I see the above splat with
>
> CONFIG_FUNCTION_TRACER=y
> CONFIG_FUNCTION_GRA
On Thu, 17 Sep 2015 16:38:52 +0200 (CEST)
Thomas Gleixner wrote:
> On Thu, 17 Sep 2015, Steven Rostedt wrote:
>
> > On Thu, 17 Sep 2015 12:13:15 +0200 (CEST)
> > Thomas Gleixner wrote:
> >
> > > Digging deeper. My assumption that it's a post powerpc merg
On Mon, 23 Nov 2015 10:35:59 +1100
Michael Ellerman wrote:
> It's mostly a tracing patch, so I'd need an ACK from Steve at least.
>
> It would probably be best if you split it into a "tracing: .. " patch which
> adds the new macros and then a powerpc patch which uses them.
Yes please do that. I
On Mon, 7 Dec 2015 17:42:42 +0300
Denis Kirjanov wrote:
> On 11/24/15, Denis Kirjanov wrote:
> > TRACE_EVENT_FN can't be used in some circumstances
> > like invoking trace functions from offlined CPU due
> > to RCU usage.
> >
> > This patch adds the TRACE_EVENT_FN_COND macro
> > to make such tra
I can take this series through my tree, but I need a acked-by from a
PPC maintainer for this patch.
-- Steve
On Tue, 24 Nov 2015 21:23:39 +0300
Denis Kirjanov wrote:
> ./drmgr -c cpu -a -r gives the following warning:
>
> [ 2327.035563]
> RCU used illegally from offline CPU!
> rcu_scheduler_
On Tue, 08 Dec 2015 08:02:15 +1100
Benjamin Herrenschmidt wrote:
> On Mon, 2015-12-07 at 15:52 -0500, Steven Rostedt wrote:
> > > + TP_CONDITION(cpu_online(smp_processor_id())),
> > > +
>
> This should probably be some kind of __raw version though, hcalls can
&g
this does solve the issue with stack tracing
kprobe events.
Reported-by: Chunyu Hu
Signed-off-by: Steven Rostedt
---
diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c
index ea43a347a104..0142c86801ba 100644
--- a/arch/powerpc/kernel/stacktrace.c
+++ b/arch/
On Wed, 09 Dec 2015 11:20:22 +1100
Michael Ellerman wrote:
> On Tue, 2015-12-08 at 13:50 -0500, Steven Rostedt wrote:
>
> > It has come to my attention that kprobe event stack tracing does not
> > work on powerpc.
>
> Yep looks like you're right. I didn'
On Wed, 09 Dec 2015 12:03:05 +1100
Michael Ellerman wrote:
> Looks like we actually have:
>
> #define kernel_stack_pointer(regs) ((regs)->gpr[1])
>
> So that would be the most self documenting way to do it I guess, though I've
> never actually seen that macro used anywhere before :)
Cool, t
On Mon, 7 Dec 2015 17:42:42 +0300
Denis Kirjanov wrote:
> On 11/24/15, Denis Kirjanov wrote:
> > TRACE_EVENT_FN can't be used in some circumstances
> > like invoking trace functions from offlined CPU due
> > to RCU usage.
> >
> > This patch adds the TRACE_EVENT_FN_COND macro
> > to make such tra
On Wed, 09 Dec 2015 12:03:05 +1100
Michael Ellerman wrote:
> > > Should I take this via powerpc or do you want it to go in via tracing?
> >
> > You can take it. And you can replace the PT_R1 if you want. I just
> > noticed that it was defined, and I try to use macro names instead of
> > hard c
On Mon, 14 Dec 2015 23:18:06 +0300
Denis Kirjanov wrote:
> ./drmgr -c cpu -a -r gives the following warning:
>
> [ 2327.035563]
> RCU used illegally from offline CPU!
> rcu_scheduler_active = 1, debug_locks = 1
> [ 2327.035564] no locks held by swapper/12/0.
> [ 2327.035565]
> stack backtrace:
>
modified
> by ftrace, because it is black listed in recordmcount.c and
> ignored by ftrace.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: linuxppc-dev@lists.ozlabs.org
> Suggested-by: Steven Rostedt
> Signed-off-by: Li Bin
Hi, can
On Wed, 16 Dec 2015 12:24:19 -0500
Steven Rostedt wrote:
> On Wed, 09 Dec 2015 12:03:05 +1100
> Michael Ellerman wrote:
>
> > > > Should I take this via powerpc or do you want it to go in via tracing?
> > > >
> > >
> > > You can take it
On Mon, 11 Jan 2016 14:30:31 +1100
Michael Ellerman wrote:
> Sorry, yep I'll take it.
>
> I trimmed the change log a bit, final version below.
>
> cheers
>
Thanks, appreciate it!
-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
> ---
> scripts/recordmcount.pl | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Steve can we get an ack for this one, to go via powerpc? cheers
Acked-by: Steven Rostedt
-- Steve
>
> diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
> ind
NT_FN_COND is already in mainline.
You can add my:
Acked-by: Steven Rostedt
-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Fri, 5 Feb 2016 15:05:17 +0100
Petr Mladek wrote:
> On Mon 2016-01-25 16:29:54, Torsten Duwe wrote:
> > diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
> > index ef8b916..29b7014 100644
> > --- a/arch/powerpc/kernel/ftrace.c
> > +++ b/arch/powerpc/kernel/ftrace.c
> > @
On Fri, 5 Feb 2016 17:18:34 +0100
Petr Mladek wrote:
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index a138f6d..de6dab0 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -449,7 +449,7 @@ config PROBE_EVENTS
> def_bool n
>
> config DYNAMIC_FTRACE
> -
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: Allow to explicitly disable the build of the dynamic
> ftrace with regs
>
> Thi
On Sat, 23 Mar 2019 09:19:50 -0400
Joe Lawrence wrote:
> Perhaps this is gcc version specific? I didn't see any other reports,
> so maybe its specific to my config. If I run make V=1, I can see that
> gcc is called with '-pg -mprofile-kernel', but then the record_mcount
> script is skipped. An
roblem.
>
> Fixes: 6977f95e63b9 ("powerpc: avoid -mno-sched-epilog on GCC 4.9 and newer").
> Signed-off-by: Joe Lawrence
Acked-by: Steven Rostedt (VMware)
-- Steve
> ---
>
> Standard disclaimer: I'm not a kbuild expert, but this works around the
> problem I repo
From: "Steven Rostedt (Red Hat)"
At Linux Plumbers, Andy Lutomirski approached me and pointed out that the
function call syscall_get_arguments() implemented in x86 was horribly
written and not optimized for the standard case of passing in 0 and 6 for
the starting index and the number
From: "Steven Rostedt (VMware)"
After removing the start and count arguments of syscall_get_arguments() it
seems reasonable to remove them from syscall_set_arguments(). Note, as of
today, there are no users of syscall_set_arguments(). But we are told that
there will be soon. But f
[ Added Peter ]
On Fri, 29 Mar 2019 19:13:55 +1000
Nicholas Piggin wrote:
> Suraj Jitindar Singh's on March 29, 2019 3:20 pm:
> > On Wed, 2019-03-27 at 17:51 +0100, Cédric Le Goater wrote:
> >> On 3/27/19 5:37 PM, Cédric Le Goater wrote:
> >> > On 3/27/19 1:36 PM, Sebastian Andrzej Siewior w
From: "Steven Rostedt (VMware)"
After removing the start and count arguments of syscall_get_arguments() it
seems reasonable to remove them from syscall_set_arguments(). Note, as of
today, there are no users of syscall_set_arguments(). But we are told that
there will be soon. But f
From: "Steven Rostedt (Red Hat)"
At Linux Plumbers, Andy Lutomirski approached me and pointed out that the
function call syscall_get_arguments() implemented in x86 was horribly
written and not optimized for the standard case of passing in 0 and 6 for
the starting index and the number
On Thu, 4 Apr 2019 21:17:58 +0300
"Dmitry V. Levin" wrote:
> There are several places listed below where I'd prefer to see more readable
> equivalents, but feel free to leave it to respective arch maintainers.
I was going to do similar changes, but figured I'd do just that (let
the arch maintain
On Tue, 12 Nov 2019 13:44:47 +0900
Sergey Senozhatsky wrote:
> > > I do recall that we talked about per-CPU printk state bit which would
> > > start/end "just print it" section. We probably can extend it to "just
> > > log_store" type of functionality. Doesn't look like a very bad idea.
> >
>
On Tue, 12 Nov 2019 11:17:47 +0900
Sergey Senozhatsky wrote:
> void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> {
> printk_emergency_enter(log_level);
> __show_stack(task, sp);
> printk_emergency_exit();
> }
> // - - - - - - - - - - - - - - - - - - -
On Wed, 6 Nov 2019 21:34:40 +0100
Peter Zijlstra wrote:
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.
Unfortunately that is the case. As my tests will fail if a backtrace i
On Wed, 6 Nov 2019 23:25:13 +
Russell King - ARM Linux admin wrote:
> On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it
On Wed, 13 Nov 2019 09:47:22 +0100
Petr Mladek wrote:
> At the moment, I am in favor of this patchset. It is huge and
> needed a lot of manual work. But the result is straightforward and
> easy to understand.
I'm in favor of this patchset too. If there's other areas that need to
adjust the curre
On Fri, 15 Nov 2019 15:28:52 -0500
Qian Cai wrote:
> # echo function >/sys/kernel/debug/tracing/current_tracer
>
> It hangs forever with today's linux-next on powerpc. Reverted the conflict fix
> [1] as below fixes the issue.
>
> [1]
> https://lore.kernel.org/linux-next/20191115135357.10386...
On Fri, 15 Nov 2019 16:06:34 -0500
Qian Cai wrote:
> > Test this commit please: b83b43ffc6e4b514ca034a0fbdee01322e2f7022
>
> # git reset --hard b83b43ffc6e4b514ca034a0fbdee01322e2f7022
>
> Yes, that one is bad.
Can you see if this patch fixes the issue for you?
Thanks!
-- Steve
diff --git
On Mon, 18 Nov 2019 09:51:04 -0500
Steven Rostedt wrote:
> > > Test this commit please: b83b43ffc6e4b514ca034a0fbdee01322e2f7022
> >
> > # git reset --hard b83b43ffc6e4b514ca034a0fbdee01322e2f7022
> >
> > Yes, that one is bad.
>
> Can you se
On Mon, 18 Nov 2019 09:58:42 -0500
Steven Rostedt wrote:
> On Mon, 18 Nov 2019 09:51:04 -0500
> Steven Rostedt wrote:
>
> > > > Test this commit please: b83b43ffc6e4b514ca034a0fbdee01322e2f7022
> > >
> > > # git reset --hard b83b43ffc6e4b514ca
On Tue, 7 Apr 2020 09:01:10 -0400
Qian Cai wrote:
> + Steven
>
> > On Apr 7, 2020, at 8:42 AM, Michael Ellerman wrote:
> >
> > Qian Cai writes:
> >> Ever since 1st Apr, linux-next starts to trigger a NULL pointer NIP on
> >> POWER9 below using
> >> this config,
> >>
> >> https://raw.githu
On Thu, 9 Apr 2020 06:06:35 -0400
Qian Cai wrote:
> >> I’ll go to bisect some more but it is going to take a while.
> >>
> >> $ git log --oneline 4c205c84e249..8e99cf91b99b
> >> 8e99cf91b99b tracing: Do not allocate buffer in trace_find_next_entry() in
> >> atomic
> >> 2ab2a0924b99 tracing: Add
On Thu, 16 Apr 2020 21:19:10 -0400
Qian Cai wrote:
> OK, reverted the commit,
>
> c55d7b5e6426 (“powerpc: Remove STRICT_KERNEL_RWX incompatibility with
> RELOCATABLE”)
>
> or set STRICT_KERNEL_RWX=n fixed the crash below and also mentioned in this
> thread,
This may be a symptom and not a cu
On Fri, 17 Apr 2020 10:57:10 +1000
Michael Ellerman wrote:
> >>> Does it needs to be a BUG_ON() ? Can't we fail gracefully with just a
> >>> WARN_ON ?
> >>>
> >>
> >> I'm not sure what failing gracefully means here? The main reason this could
> >> fail is if there is not enough memory to alloc
On Thu, 23 Apr 2020 18:21:14 +0200
Christophe Leroy wrote:
> Le 23/04/2020 à 17:09, Naveen N. Rao a écrit :
> > With STRICT_KERNEL_RWX, we are currently ignoring return value from
> > __patch_instruction() in do_patch_instruction(), resulting in the error
> > not being propagated back. Fix the sa
On Thu, 23 Apr 2020 17:41:52 +0200
Christophe Leroy wrote:
> > diff --git a/arch/powerpc/kernel/optprobes.c
> > b/arch/powerpc/kernel/optprobes.c
> > index 024f7aad1952..046485bb0a52 100644
> > --- a/arch/powerpc/kernel/optprobes.c
> > +++ b/arch/powerpc/kernel/optprobes.c
> > @@ -139,52 +139,
1 - 100 of 606 matches
Mail list logo
