linux-kernel - Re: [PATCH 00/16] [GIT PULL] tracing: fixes/cleanups, no stop-machine, update stack tracer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 1 Jan 2012 19:09:50 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH 00/16] [GIT PULL] tracing: fixes/cleanups, no
 stop-machine, update stack tracer


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

> Ingo,
> 
> This patch set contains a few things.
> 
> 1) various fixes and cleanups, one is even marked as stable, but its
>    a minor bug fix that probably is not worth pushing to mainline this
>    late in the -rc.
> 
> 2) The infrastructure to use ftrace function tracing without stop_machine.
>   Although x86 doesn't have the iret code finished to do this yet,
>   other archs like PPC can. This will also test out the code better.
>   Note, it's just a single patch left that converts x86 to use this code.
> 
> 3) Moving the stack tracer to its own function list. As Jiri is
>    working on having perf do function tracing, he found a few bugs
>    that were hard to find without another user outside the global users.
>    It makes sense to have the stack tracer separate from the function
>    tracer anyway, and it gives a good test bed for perf and function
>    tracing as well.
> 
> -- Steve
> 
> Please pull the latest tip/perf/core tree, which can be found at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
> tip/perf/core
> 
> Head SHA1: 38b78eb855409a05f9d370228bec1955e6878e08
> 
> 
> Jiri Olsa (1):
>       ftrace: Fix unregister ftrace_ops accounting
> 
> Steven Rostedt (14):
>       ftrace: Do not function trace inlined functions
>       ftrace: Allow archs to modify code without stop machine
>       ftrace: Remove usage of "freed" records
>       ftrace: Allocate the mcount record pages as groups
>       ftrace: Replace record newlist with record page list
>       ftrace: Sort the mcount records on each page
>       ftrace: Use bsearch to find record ip
>       ftrace: Fix ftrace hash record update with notrace
>       ftrace: Create ftrace_hash_empty() helper routine
>       ftrace: Allow other users of function tracing to use the output listing
>       ftrace: Decouple hash items from showing filtered functions
>       tracing: Have stack_tracer use a separate list of functions
>       ftrace: Allow access to the boot time function enabling
>       tracing: Have stack tracing set filtered functions at boot
> 
> Tejun Heo (1):
>       tracing: Factorize filter creation
> 
> ----
>  Documentation/kernel-parameters.txt |    8 +
>  include/linux/compiler-gcc.h        |    5 +
>  include/linux/ftrace.h              |   76 ++++-
>  kernel/trace/ftrace.c               |  715 +++++++++++++++++++++++++----------
>  kernel/trace/trace_events_filter.c  |  283 +++++++-------
>  kernel/trace/trace_stack.c          |   30 ++-
>  6 files changed, 767 insertions(+), 350 deletions(-)

Hm, i'm seeing spontaneous reboot crashes with these commits 
applied. The reboots just happen out of the blue during an 
allyesconfig bootup (config attached), and they happen at
random places.

In about 50% of the cases the kernel boots up fine - so 
bisection is very difficult - i have to repeat the bootup 10 
times to have a reasonable confidence during a 5-step bisection 
process.

I've narrowed it down the commits in the above tree:

38b78eb85540: tracing: Factorize filter creation
762e1207889b: tracing: Have stack tracing set filtered functions at boot
2a85a37f168d: ftrace: Allow access to the boot time function enabling
d2d45c7a03a2: tracing: Have stack_tracer use a separate list of functions
69a3083c4a7d: ftrace: Decouple hash items from showing filtered functions
fc13cb0ce452: ftrace: Allow other users of function tracing to use the output listing
06a51d930738: ftrace: Create ftrace_hash_empty() helper routine
c842e975520f: ftrace: Fix ftrace hash record update with notrace
5855fead9cc3: ftrace: Use bsearch to find record ip
68950619f8c8: ftrace: Sort the mcount records on each page
85ae32ae019b: ftrace: Replace record newlist with record page list
a79008755497: ftrace: Allocate the mcount record pages as groups
3208230983a0: ftrace: Remove usage of "freed" records
c88fd8634ea6: ftrace: Allow archs to modify code without stop machine
45959ee7aa64: ftrace: Do not function trace inlined functions
30fb6aa74011: ftrace: Fix unregister ftrace_ops accounting

-tip commit 1bc2a3035df2 appears to be fine, it survived 10 
consecutive reboots.

So i'm a bit stuck - i wanted to pull this and the NMI bits. 
I'll test the NMI bits independently as well, excluding the 
above commits, so that we can at least move forward on that 
topic.

Thanks,

	Ingo

View attachment "config" of type "text/plain" (124776 bytes)