[PATCH] tracing: Fix TRACING_SUPPORT dependency

[PATCH] tracing: Fix TRACING_SUPPORT dependency

[Anton Vorontsov]

commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean up
menu"), despite the "clean up" in its purpose, introduced behavioural
change for Kconfig symbols: we no longer able to select tracing
support on PPC32 (because IRQFLAGS_SUPPORT isn't yet implemented).

The IRQFLAGS_SUPPORT is not mandatory for most tracers, tracing core
has a special case for platforms w/o irqflags (which, by the way, has
become useless as of the commit above).

This patch restores the old behaviour, and thus brings the tracing
back on PPC32.

p.s.
The IRQSOFF_TRACER (which is the only tracer that requires IRQFLAGS
support) still depends on TRACE_IRQFLAGS_SUPPORT Kconfig symbol.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 kernel/trace/Kconfig |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index ee70841..774aba7 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -63,7 +63,6 @@ config TRACING
 #
 config TRACING_SUPPORT
 	bool
-	depends on TRACE_IRQFLAGS_SUPPORT
 	depends on STACKTRACE_SUPPORT
 	default y
 
-- 
1.5.6.5

Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency

[Ingo Molnar]

* Anton Vorontsov <avorontsov@ru.mvista.com> wrote:

> commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean 
> up menu"), despite the "clean up" in its purpose, introduced 
> behavioural change for Kconfig symbols: we no longer able to 
> select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't 
> yet implemented).

Could you please solve this by implementing proper irqflag-tracing 
support? It's been available upstream for almost three years. It's 
needed for lockdep support as well, etc.

	Ingo

Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency

[Anton Vorontsov]

On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
> 
> * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> 
> > commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean 
> > up menu"), despite the "clean up" in its purpose, introduced 
> > behavioural change for Kconfig symbols: we no longer able to 
> > select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't 
> > yet implemented).
> 
> Could you please solve this by implementing proper irqflag-tracing 
> support? It's been available upstream for almost three years. It's 
> needed for lockdep support as well, etc.

Breaking things via clean up patches is an interesting method of
encouraging something to implement. ;-)

Surely I'll look into implementing irqflags tracing, but considering
that no one ever needed this for almost three years, and that we
explicitly have the code to deal with tracing-w/o-irqflags, can we
please restore the old behaviour?

At least for 2.6.30, because I don't think I'll have enough time to
implement/test/push irqflags tracing support in time for 2.6.30-rc1.

Thanks,

p.s.
It would make more sense if 40ada30f's commit message would state
that tracing w/o irqflags is now obsolete, or better, if it was
discussed on some mailinglist, so that we'd have some time to
adapt the architecture-specific code.

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency

[Ingo Molnar]

* Anton Vorontsov <avorontsov@ru.mvista.com> wrote:

> On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
> > 
> > * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > 
> > > commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean 
> > > up menu"), despite the "clean up" in its purpose, introduced 
> > > behavioural change for Kconfig symbols: we no longer able to 
> > > select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't 
> > > yet implemented).
> > 
> > Could you please solve this by implementing proper 
> > irqflag-tracing support? It's been available upstream for almost 
> > three years. It's needed for lockdep support as well, etc.
> 
> Breaking things via clean up patches is an interesting method of 
> encouraging something to implement. ;-)
>
> Surely I'll look into implementing irqflags tracing, but 
> considering that no one ever needed this for almost three years, 
> [...]

Weird, there's no lockdep support?

	Ingo

Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency

[Anton Vorontsov]

On Fri, Mar 20, 2009 at 08:57:43PM +0100, Ingo Molnar wrote:
> 
> * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> 
> > On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
> > > 
> > > * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > > 
> > > > commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean 
> > > > up menu"), despite the "clean up" in its purpose, introduced 
> > > > behavioural change for Kconfig symbols: we no longer able to 
> > > > select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't 
> > > > yet implemented).
> > > 
> > > Could you please solve this by implementing proper 
> > > irqflag-tracing support? It's been available upstream for almost 
> > > three years. It's needed for lockdep support as well, etc.
> > 
> > Breaking things via clean up patches is an interesting method of 
> > encouraging something to implement. ;-)
> >
> > Surely I'll look into implementing irqflags tracing, but 
> > considering that no one ever needed this for almost three years, 
> > [...]
> 
> Weird, there's no lockdep support?

*ashamed*: apparently no such support currently exist for PPC32. ;-)

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency

[Ingo Molnar]

* Anton Vorontsov <avorontsov@ru.mvista.com> wrote:

> On Fri, Mar 20, 2009 at 08:57:43PM +0100, Ingo Molnar wrote:
> > 
> > * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > 
> > > On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > > > 
> > > > > commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean 
> > > > > up menu"), despite the "clean up" in its purpose, introduced 
> > > > > behavioural change for Kconfig symbols: we no longer able to 
> > > > > select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't 
> > > > > yet implemented).
> > > > 
> > > > Could you please solve this by implementing proper 
> > > > irqflag-tracing support? It's been available upstream for almost 
> > > > three years. It's needed for lockdep support as well, etc.
> > > 
> > > Breaking things via clean up patches is an interesting method of 
> > > encouraging something to implement. ;-)
> > >
> > > Surely I'll look into implementing irqflags tracing, but 
> > > considering that no one ever needed this for almost three years, 
> > > [...]
> > 
> > Weird, there's no lockdep support?
> 
> *ashamed*: apparently no such support currently exist for PPC32. ;-)

Hm, do all the tracers even compile on ppc32 with your patch?

We had periodic build failures on weird, unmaintained architectures 
that had no irqflags-tracing support and hence didnt know the 
raw_irqs_save/restore primitives ...

I'm not trying to make things more difficult for you (and we can 
apply your patch if it builds fine and does not cause problems 
elsewhere), but there were some real downsides to not having proper 
irq APIs ...

	Ingo

Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency

[Steven Rostedt]

On Sat, 21 Mar 2009, Ingo Molnar wrote:

> 
> * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> 
> > On Fri, Mar 20, 2009 at 08:57:43PM +0100, Ingo Molnar wrote:
> > > 
> > > * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > > 
> > > > On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
> > > > > 
> > > > > * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > > > > 
> > > > > > commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean 
> > > > > > up menu"), despite the "clean up" in its purpose, introduced 
> > > > > > behavioural change for Kconfig symbols: we no longer able to 
> > > > > > select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't 
> > > > > > yet implemented).
> > > > > 
> > > > > Could you please solve this by implementing proper 
> > > > > irqflag-tracing support? It's been available upstream for almost 
> > > > > three years. It's needed for lockdep support as well, etc.
> > > > 
> > > > Breaking things via clean up patches is an interesting method of 
> > > > encouraging something to implement. ;-)
> > > >
> > > > Surely I'll look into implementing irqflags tracing, but 
> > > > considering that no one ever needed this for almost three years, 
> > > > [...]
> > > 
> > > Weird, there's no lockdep support?
> > 
> > *ashamed*: apparently no such support currently exist for PPC32. ;-)
> 
> Hm, do all the tracers even compile on ppc32 with your patch?
> 
> We had periodic build failures on weird, unmaintained architectures 
> that had no irqflags-tracing support and hence didnt know the 
> raw_irqs_save/restore primitives ...
> 
> I'm not trying to make things more difficult for you (and we can 
> apply your patch if it builds fine and does not cause problems 
> elsewhere), but there were some real downsides to not having proper 
> irq APIs ...

Note, the issue is not with the hooks into local_irq_save/restore, but 
with the entry.S code. That code is very sensitive where the irqs are 
enabled and disabled.

-- Steve

Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency

[Ingo Molnar]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> 
> On Sat, 21 Mar 2009, Ingo Molnar wrote:
> 
> > 
> > * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > 
> > > On Fri, Mar 20, 2009 at 08:57:43PM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > > > 
> > > > > On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
> > > > > > 
> > > > > > * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > > > > > 
> > > > > > > commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean 
> > > > > > > up menu"), despite the "clean up" in its purpose, introduced 
> > > > > > > behavioural change for Kconfig symbols: we no longer able to 
> > > > > > > select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't 
> > > > > > > yet implemented).
> > > > > > 
> > > > > > Could you please solve this by implementing proper 
> > > > > > irqflag-tracing support? It's been available upstream for almost 
> > > > > > three years. It's needed for lockdep support as well, etc.
> > > > > 
> > > > > Breaking things via clean up patches is an interesting method of 
> > > > > encouraging something to implement. ;-)
> > > > >
> > > > > Surely I'll look into implementing irqflags tracing, but 
> > > > > considering that no one ever needed this for almost three years, 
> > > > > [...]
> > > > 
> > > > Weird, there's no lockdep support?
> > > 
> > > *ashamed*: apparently no such support currently exist for PPC32. ;-)
> > 
> > Hm, do all the tracers even compile on ppc32 with your patch?
> > 
> > We had periodic build failures on weird, unmaintained architectures 
> > that had no irqflags-tracing support and hence didnt know the 
> > raw_irqs_save/restore primitives ...
> > 
> > I'm not trying to make things more difficult for you (and we can 
> > apply your patch if it builds fine and does not cause problems 
> > elsewhere), but there were some real downsides to not having proper 
> > irq APIs ...
> 
> Note, the issue is not with the hooks into local_irq_save/restore, 
> but with the entry.S code. That code is very sensitive where the 
> irqs are enabled and disabled.

i know. What i'm talking about is that non-lockdep architectures 
have the habit of not defining raw_local_irq_save() - which the 
tracing core relies on.

	Ingo

Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency

[Steven Rostedt]

On Sat, 21 Mar 2009, Ingo Molnar wrote:
> > > 
> > > Hm, do all the tracers even compile on ppc32 with your patch?
> > > 
> > > We had periodic build failures on weird, unmaintained architectures 
> > > that had no irqflags-tracing support and hence didnt know the 
> > > raw_irqs_save/restore primitives ...
> > > 
> > > I'm not trying to make things more difficult for you (and we can 
> > > apply your patch if it builds fine and does not cause problems 
> > > elsewhere), but there were some real downsides to not having proper 
> > > irq APIs ...
> > 
> > Note, the issue is not with the hooks into local_irq_save/restore, 
> > but with the entry.S code. That code is very sensitive where the 
> > irqs are enabled and disabled.
> 
> i know. What i'm talking about is that non-lockdep architectures 
> have the habit of not defining raw_local_irq_save() - which the 
> tracing core relies on.

Since we know that's not an issue with PPC32, perhaps we should add (I 
hate to do this)...


	depends on TRACE_IRQFLAGS_SUPPORT || PPC32

And document that the "|| PPC32" should go when PowerPC32 gets its act
together.  :-/

-- Steve

Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency

[Steven Rostedt]

On Sat, 21 Mar 2009, Steven Rostedt wrote:
> 
> Since we know that's not an issue with PPC32, perhaps we should add (I 
> hate to do this)...
> 
> 
> 	depends on TRACE_IRQFLAGS_SUPPORT || PPC32
> 
> And document that the "|| PPC32" should go when PowerPC32 gets its act
> together.  :-/

Note, the only tracer broken on PPC32 is the IRQSOFF tracer, and that 
already depends on TRACE_IRQFLAGS_SUPPORT.

-- Steve

Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency

[Ingo Molnar]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> 
> On Sat, 21 Mar 2009, Steven Rostedt wrote:
> > 
> > Since we know that's not an issue with PPC32, perhaps we should add (I 
> > hate to do this)...
> > 
> > 
> > 	depends on TRACE_IRQFLAGS_SUPPORT || PPC32
> > 
> > And document that the "|| PPC32" should go when PowerPC32 gets its act
> > together.  :-/
> 
> Note, the only tracer broken on PPC32 is the IRQSOFF tracer, and 
> that already depends on TRACE_IRQFLAGS_SUPPORT.

Ok, that's fine with me too. Perhaps we could add a TRACING_SUPPORT 
thing that architectures can enable - but it's probably overkill in 
this case.

	Ingo

[PATCH] tracing: Fix TRACING_SUPPORT dependency for PPC32

[Anton Vorontsov]

commit 40ada30f9621fbd831ac2437b9a2a399aa ("tracing: clean up menu"),
despite the "clean up" in its purpose, introduced a behavioural
change for Kconfig symbols: we no longer able to select tracing
support on PPC32 (because IRQFLAGS_SUPPORT isn't yet implemented).

The IRQFLAGS_SUPPORT is not mandatory for most tracers, tracing core
has a special case for platforms w/o irqflags (which, by the way, has
become useless as of the commit above).

Though according to Ingo Molnar, there was periodic build failures on
weird, unmaintained architectures that had no irqflags-tracing support
and hence didn't know the raw_irqs_save/restore primitives. Thus we'd
better not enable irqflags-less tracing for all architectures.

This patch restores the old behaviour for PPC32, and thus brings the
tracing back. Other architectures can either add themselves to the
exception list or (better) implement TRACE_IRQFLAGS_SUPPORT.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---

On Sat, Mar 21, 2009 at 05:18:14PM +0100, Ingo Molnar wrote:
[...]
> > > > Surely I'll look into implementing irqflags tracing, but 
> > > > considering that no one ever needed this for almost three years, 
> > > > [...]
> > > 
> > > Weird, there's no lockdep support?
> > 
> > *ashamed*: apparently no such support currently exist for PPC32. ;-)
> 
> Hm, do all the tracers even compile on ppc32 with your patch?

Following config compiles fine:

$ grep TRAC .config
CONFIG_STACKTRACE_SUPPORT=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_PREEMPT_RCU_TRACE is not set
CONFIG_TRACEPOINTS=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_STACKTRACE=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACING=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_EVENT_TRACER=y
CONFIG_BOOT_TRACER=y
# CONFIG_TRACE_BRANCH_PROFILING is not set
CONFIG_STACK_TRACER=y
CONFIG_KMEMTRACE=y
CONFIG_WORKQUEUE_TRACER=y
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_DYNAMIC_FTRACE=y
CONFIG_FTRACE_MCOUNT_RECORD=y
CONFIG_FTRACE_SELFTEST=y
CONFIG_FTRACE_STARTUP_TEST=y

With CONFIG_TRACE_BRANCH_PROFILING=y the kernel builds fine too,
but vmlinux is too big to boot (we still can boot it, but we'll
need a bit modified bootloader for that).

OK, how about the patch down below?

 kernel/trace/Kconfig |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index ee70841..2246141 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -63,7 +63,11 @@ config TRACING
 #
 config TRACING_SUPPORT
 	bool
-	depends on TRACE_IRQFLAGS_SUPPORT
+	# PPC32 has no irqflags tracing support, but it can use most of the
+	# tracers anyway, they were tested to build and work. Note that new
+	# exceptions to this list aren't welcomed, better implement the
+	# irqflags tracing for your architecture.
+	depends on TRACE_IRQFLAGS_SUPPORT || PPC32
 	depends on STACKTRACE_SUPPORT
 	default y
 
-- 
1.5.6.5

Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency for PPC32

[Steven Rostedt]

On Tue, 24 Mar 2009, Anton Vorontsov wrote:

> commit 40ada30f9621fbd831ac2437b9a2a399aa ("tracing: clean up menu"),
> despite the "clean up" in its purpose, introduced a behavioural
> change for Kconfig symbols: we no longer able to select tracing
> support on PPC32 (because IRQFLAGS_SUPPORT isn't yet implemented).
> 
> The IRQFLAGS_SUPPORT is not mandatory for most tracers, tracing core
> has a special case for platforms w/o irqflags (which, by the way, has
> become useless as of the commit above).
> 
> Though according to Ingo Molnar, there was periodic build failures on
> weird, unmaintained architectures that had no irqflags-tracing support
> and hence didn't know the raw_irqs_save/restore primitives. Thus we'd
> better not enable irqflags-less tracing for all architectures.
> 
> This patch restores the old behaviour for PPC32, and thus brings the
> tracing back. Other architectures can either add themselves to the
> exception list or (better) implement TRACE_IRQFLAGS_SUPPORT.
> 
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
[..]

> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index ee70841..2246141 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -63,7 +63,11 @@ config TRACING
>  #
>  config TRACING_SUPPORT
>  	bool
> -	depends on TRACE_IRQFLAGS_SUPPORT
> +	# PPC32 has no irqflags tracing support, but it can use most of the
> +	# tracers anyway, they were tested to build and work. Note that new
> +	# exceptions to this list aren't welcomed, better implement the
> +	# irqflags tracing for your architecture.
> +	depends on TRACE_IRQFLAGS_SUPPORT || PPC32
>  	depends on STACKTRACE_SUPPORT
>  	default y
> 

I'm fine with this.

Acked-by: Steven Rostedt <srostedt@redhat.com>

-- Steve

Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency

[Benjamin Herrenschmidt]

> > Weird, there's no lockdep support?
> 
> *ashamed*: apparently no such support currently exist for PPC32. ;-)

Actually there is a patch that's been floating around (from Dale
Farnsworth) for adding irqtrace/lockdep to ppc32 but it seems to be
buggy :-) IE, it causes crashes and I haven't had a chance
to try to find out yet. I'll probably give it another go one of these
days, but if you want to play with it, I'll send it to you directly.

Cheers,
Ben.

Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency

[Steven Rostedt]

Ug, My Red Hat email was not being updated. I totally missed this
thread.

On Fri, 2009-03-20 at 20:57 +0100, Ingo Molnar wrote:
> * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> 
> > On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
> > > 
> > > * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > > 
> > > > commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean 
> > > > up menu"), despite the "clean up" in its purpose, introduced 
> > > > behavioural change for Kconfig symbols: we no longer able to 
> > > > select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't 
> > > > yet implemented).
> > > 
> > > Could you please solve this by implementing proper 
> > > irqflag-tracing support? It's been available upstream for almost 
> > > three years. It's needed for lockdep support as well, etc.
> > 
> > Breaking things via clean up patches is an interesting method of 
> > encouraging something to implement. ;-)
> >
> > Surely I'll look into implementing irqflags tracing, but 
> > considering that no one ever needed this for almost three years, 
> > [...]
> 
> Weird, there's no lockdep support?

I've discussed this with several people before. lockdep exists for
PPC64, but apparently it does not work for PPC32. There's been ongoing
work in this area, but unfortunately, nothing stable has come out of it.

I believe Dale was the last one to be working on this.

-- Steve