linux-kernel - Re: [PATCH 0/5] [GIT PULL] updates for tip

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 16 Apr 2009 11:51:35 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH 0/5] [GIT PULL] updates for tip


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

> Ingo,
> 
> Please pull the latest tip/tracing/core tree, which can be found at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> tip/tracing/core
> 
> 
> Avadh Patel (1):
>       tracing: add saved_cmdlines file to show cached task comms
> 
> Steven Rostedt (4):
>       ftrace: use module notifier for function tracer
>       tracing/events: add startup tests for events
>       tracing/events: add rcu locking around trace event prints
>       tracing/events/ring-buffer: expose format of ring buffer headers to users
> 
> ----
>  include/linux/ftrace.h      |    7 --
>  include/linux/module.h      |    4 +
>  include/linux/ring_buffer.h |    5 +
>  include/trace/ftrace.h      |    4 +
>  kernel/module.c             |   19 ++---
>  kernel/trace/ftrace.c       |   90 +++++++++++++-----
>  kernel/trace/ring_buffer.c  |   44 +++++++++
>  kernel/trace/trace.c        |   53 +++++++++++
>  kernel/trace/trace_events.c |  214 +++++++++++++++++++++++++++++++++++++++++++
>  9 files changed, 395 insertions(+), 45 deletions(-)

Pulled, thanks Steve!

I see one particular self-test failure - i've attached config and 
dmesg snippet.

One thing becomes apparent from a quick glance at the dmesg: it's 
not entirely obvious to see which event test failed. Here:

        sysname = kmalloc(4, GFP_KERNEL);
        if (WARN_ON(!sysname)) {
                pr_warning("Can't allocate memory, giving up!\n");
                return 0;
        }
        memcpy(sysname, "*:*", 4);
        ret = ftrace_set_clr_event(sysname, 1);
        if (WARN_ON_ONCE(ret)) {
                kfree(sysname);
                pr_warning("error enabling all events\n");
                return 0;
        }

        event_test_stuff();

we should probably print "sysname" in that failure path, right? 

This:

	if (WARN_ONCE(KERN_CONT "%s: failed! ret: %d\n", sysname, ret)) {
		...
	}

would suffice, right?

	Ingo

[   31.788741] calling  event_trace_self_tests+0x0/0x374 @ 1
[   31.794194] Running tests on trace events:
[   31.798346] Running tests on trace event systems:
[   31.803104] Running tests on all trace events:
[   31.807601] Testing all events: <4>------------[ cut here ]------------
[   31.814353] WARNING: at kernel/trace/trace_events.c:1112 event_trace_self_tests+0x2b7/0x374()
[   31.822943] Hardware name: System Product Name
[   31.827440] Modules linked in:
[   31.830376] Pid: 1, comm: swapper Not tainted 2.6.30-rc2-tip #4157
[   31.836835] Call Trace:
[   31.839340]  [<ffffffff8024f510>] warn_slowpath+0xd8/0xf7
[   31.844808]  [<ffffffff8027174d>] ? __lock_acquire+0x1c7/0x2c3
[   31.850700]  [<ffffffff80983d37>] ? __mutex_lock_common+0xa7/0x391
[   31.856933]  [<ffffffff8027209a>] ? __lock_release+0x3f/0x58
[   31.862653]  [<ffffffff80983c49>] ? __mutex_unlock_slowpath+0x13/0x15
[   31.869153]  [<ffffffff80983c49>] ? __mutex_unlock_slowpath+0x13/0x15
[   31.875653]  [<ffffffff80983c59>] ? mutex_unlock+0xe/0x10
[   31.881121]  [<ffffffff802a905d>] ? ftrace_set_clr_event+0x126/0x138
[   31.887526]  [<ffffffff80f0a25b>] event_trace_self_tests+0x2b7/0x374
[   31.893940]  [<ffffffff80f09fa4>] ? event_trace_self_tests+0x0/0x374
[   31.900361]  [<ffffffff80209251>] do_one_initcall+0x5b/0x140
[   31.906081]  [<ffffffff8028f8af>] ? register_irq_proc+0xb3/0xcf
[   31.912055]  [<ffffffff80ef3140>] ? early_idt_handler+0x0/0x73
[   31.917948]  [<ffffffff80ef36b9>] do_initcalls+0x1e/0x30
[   31.923321]  [<ffffffff80ef36e8>] do_basic_setup+0x1d/0x1f
[   31.928866]  [<ffffffff80ef3a30>] kernel_init+0x5b/0x9c
[   31.934154]  [<ffffffff8020d40a>] child_rip+0xa/0x20
[   31.939181]  [<ffffffff8020cd90>] ? restore_args+0x0/0x30
[   31.944641]  [<ffffffff80ef39d5>] ? kernel_init+0x0/0x9c
[   31.950015]  [<ffffffff8020d400>] ? child_rip+0x0/0x20
[   31.955215] ---[ end trace fae59924f2398594 ]---
[   31.959885] error enabling all events
[   31.963604] initcall event_trace_self_tests+0x0/0x374 returned 0 after 165439 usecs
[   31.971326] calling  max_swapfiles_check+0x0/0x8 @ 1
[   31.976344] initcall max_swapfiles_check+0x0/0x8 returned 0 after 1 usecs

View attachment "config-Thu_Apr_16_10_40_02_CEST_2009.bad" of type "text/plain" (69412 bytes)