linux-kernel - Re: [RFC PATCH 0/1] trace: Add early event trace support

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:	Wed, 15 Aug 2012 16:37:54 -0300
From:	Ezequiel Garcia <elezegarcia@...il.com>
To:	rostedt@...dmis.org, linux-kernel@...r.kernel.org
Cc:	Pekka Enberg <penberg@...nel.org>, Ingo Molnar <mingo@...hat.com>,
	Tim Bird <tim.bird@...sony.com>, lizefan@...wei.com,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC PATCH 0/1] trace: Add early event trace support

On Wed, Aug 15, 2012 at 12:20 PM, Ezequiel Garcia <elezegarcia@...il.com> wrote:
> Hi Steven,
>
> This patch is my first attempt to address the "early tracing issue".
> Right now, trace events are registered on fs_initcall, which is very late
> if you want to capture boot-up events.
>
> This feature is in developers wish list as this old (2009) thread shows [1].
>
> By splitting the initialization, separating the ftrace enable from the
> sysfs entry
> creation, it is possible to move events enable to early_initcall.
> (which is also late, but I wouldn't expect more from such a small patch).
>
> Without this patch, and using
> "trace_event=kmem:kmalloc,kmem:kmalloc_node,kmem:kfree"
> as kernel parameter, on a bare kernel I can start capturing kmallocs
> from ~0.4 secs,
> and I get 186 callers.
>
> This patch moves the capture to ~ 0.2 secs and captures 220 callers.
>
> The caller count is inaccurate since gcc does some automatic inlining
> (I have another RFC PATCH for that), but it shows a rough increase.
>
> Also, this enable is not time-consuming:
> [    0.190000] calling  event_trace_enable+0x0/0xad @ 1
> [    0.190000] initcall event_trace_enable+0x0/0xad returned 0 after 0 usecs
>
> This patch is intended to trigger this discussion: to be honest I'm
> not sure how ugly
> this is. So some feedback about it would be greatly appreciated.
>
> Also, I'd like to ask for some guidelines (not solutions, just some guidelines)
> on how to attack this problem.
> I'm interesting on capturing kmem events, from the very first kmalloc onwards.
> Though, it would be nice to extend the solution to other event classes.
>
> Thanks,
> Ezequiel.
>
> [1] http://lkml.indiana.edu/hypermail/linux/kernel/0911.3/00036.html


I forgot to add this work is part of a project funded by CE workgroup.
You can find more details here:

http://elinux.org/Kernel_dynamic_memory_allocation_tracking_and_reduction

Thanks,
Ezequiel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/