lkml.org 
[lkml]   [2009]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/3] trace: fix default boot up tracer

On Mon, 2 Feb 2009, Andrew Morton wrote:
> >
> > The lock_kernel addition was added when the BKL became a spinlock again.
> > The selftests needed to be able to sleep, and this caused issues.
>
> Sleeping inside lock_kernel() is quite OK. Confused.

I did not explain that quite well. I need to focus on the emails
that I write, and not do it half concentrating on code that I'm
also writing :-/

The preempt tracer expects preemption enabled when the self test is
executed. Because the self test for preempt tracer is basically:

start_trace();
preempt_disable();
udelay(x);
preempt_enable();
stop_trace();

make sure we have a delay.

This failed, because lock_kernel now disables preemption. So that
preempt_disable() never triggers the trace, and the test sees that nothing
was recorded. This causes a failure to be flagged, and we disable the
preempt tracer.

>
> What is the call path to this function? Does it all happen under
> ftrace_init()? If not, do we risk breaking start_kernel()'s
> thou-shalt-not-enable-interrupts-early rule which powerpc (at least)
> imposes?

This function is always called via the initcall functions.

>
> > The register_tracer was initial written to be pluggable at any time.
> > Perhaps in the future to allow modules. But this does not seem to have
> > panned out.
> >
> > Since we have the lock_kernel there anyway, if we ever need to handle
> > modules, that will need a different interface anyway. I guess I can nuke
> > the unregister tracer.
>
> And add some __init/__initdatas?

I'll take some time to analyze what can be annotated.

-- Steve
>


\
 
 \ /
  Last update: 2009-02-03 05:37    [W:0.054 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site