Re: [PATCH 1/2] tracing/ftrace: don't trace on early stage of secondary cpu boot

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 24 Dec 2008, Fr?d?ric Weisbecker wrote:
> >>       /*
> >> @@ -1233,7 +1233,7 @@ int trace_graph_entry(struct ftrace_graph_ent *trace)
> >>       int cpu;
> >>       int pc;
> >>
> >> -     if (!ftrace_trace_task(current))
> >> +     if (!ftrace_trace_task(current) || ftrace_in_early_cpuinit())
> >>               return 0;
> >
> > Actually, didn't you say current is not available either? We are testing
> > current first.
> 
> Oops. Strange, my tests didn't give me any problem.
> I will fix it.

Are you sure 'current' is dangerous? Perhaps we do not need to worry here, 
since we are testing current against something else, and if the CPU
is just coming on line, it will not be the task we want.

> 
> 
> > I still wonder if there's a better way to find out if it is safe to run.
> > Perhaps the arch code can test the %gs register to see if it is actually
> > something valid?
> >
> > -- Steve
> 
> I could test if MSR_GS_BASE references cpu_pda(cpu) but that remains
> as much heavy...

Perhaps just reading the %gs register and see if it faults would be good 
enough?

	long dummy;
	int faulted=0;

	    asm(
		"1:	movq %%gs:0, %0\n"
		"2:
		".section .fixup \"ax\"\n"
		"3:	movl $1, %1\n"
		"	jmp 2b\n"
		".previous"
		_ASM_EXTABLE(1b, 3b)
		: "=r"(dummy), "=r"(faulted)
		: "1"(faulted));


Would this work?  On the good cases, all we do is a read of the %gs 
section, which is the same as doing a smp_process_id(). On the bad case, 
we fault, but we also catch that fact. We are more interested in the good 
case being fast. but I'm not sure how well the start up code could take a 
fault, even when it is expected.

-- Steve