linux-kernel - Re: [RFC PATCH 1/1] trace: Move trace event enable from fs_initcall to early

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]

Message-ID: <1345214379.3708.29.camel@gandalf.local.home>
Date:	Fri, 17 Aug 2012 10:39:39 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ezequiel Garcia <elezegarcia@...il.com>
Cc:	linux-kernel@...r.kernel.org, Pekka Enberg <penberg@...nel.org>,
	tim.bird@...sony.com, lizefan@...wei.com,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>, Jason Baron <jbaron@...hat.com>
Subject: Re: [RFC PATCH 1/1] trace: Move trace event enable from fs_initcall
 to early_initcall

On Fri, 2012-08-17 at 11:04 -0300, Ezequiel Garcia wrote:
> On Fri, Aug 17, 2012 at 10:55 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> > On Fri, 2012-08-17 at 08:01 -0300, Ezequiel Garcia wrote:
> >
> >> Regarding the 'complete solution': to be able to capture events from
> >> the very beggining...
> >> Have you thought about this?
> >> Could you give me a hint on how could I implement it?
> >
> > How far in the "beginning"? Before memory is set up?
> 
> Yes.
> 
> > I wouldn't do that.
> 
> Yeah, perhaps it sounds crazy. It makes some sense for kmem events, though.

It doesn't sound crazy, because I've done it before. There may be ways
to do it.

> 
> > I have in the past (set up before memory was finished being
> > initialized), but things have changed since then.
> >
> > One thing that we could do for those that want really early tracing, is
> > to add a config option to add a static temporary ring buffer, that gets
> 
> Yes, something like this would be ideal. How would this ring buffer be
> allocated?
> Perhaps as static and __initdata?

Yes.

> This way it would be released afterwards, right?

Correct.

> 
> > copied into the default ring buffer after memory is set up. That may be
> > the easiest way.
> >
> > Once memory is set up, the ring buffer can be allocated and events can
> > be traced, but the ring buffer needs to be set up first. All it would
> > take is some calls in init/main.c start_kernel() to the initialization.
> >
> 
> Note that my main concern is on trace_events (kmem events to be precise).
> However this are registered through tracepoints and in turn this tracepoints
> depend on kmalloc and friends. So, right now is a chicken-egg problem.

I don't think kmalloc is the issue. The big problem in front of you is
jump labels. That's what enables and disables trace points, and it gets
initialized just after memory is set up. You may have to force jump
labels off when doing early tracing :-/ Although I'm not sure it
requires allocations.

-- Steve


--
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/