Re: [PATCH 3/3] tracing/function-return-tracer: add the overrunfield

[Steven Rostedt]

On Tue, 18 Nov 2008, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> > 
> > I was just looking at the stack tracer, and it pretty much gives us 
> > the answer ;-) I'm hitting on max traces around 55, but some of 
> > those are asm calls. We could do 50 or 60?  We probably want to make 
> > sure that the two do not come close to hitting. That is, the bottom 
> > of the stack to overwrite the saved return addresses.
> 
> does the stack tracer properly nest across IRQ entry boundaries 
> already on x86? We used to have problems in that area.

Actually, because the stack tracer is in generic code, we punt on IRQ 
stacks:

	/* we do not handle interrupt stacks yet */
	if (!object_is_on_stack(&this_size))
		return;

I check if the local variable "this_size" is on the current->stack and if 
it is not then this means that we are using some other stack, and we do 
not record it.

What would be needed is to make a per-arch stack call. Perhaps have a:

   arch_check_stack(&this_size, &max_stack_trace, &max_stack_size);

Where a weak function can be defined to return nothing. But the arch can 
check which stack the "this_size" variable is on and run the stack tracer 
against that stack.

Maybe we should have two stack traces, a stack_trace file and a 
stack_trace_irq ?

Because, some archs, like x86_64 have different size stacks. The thread 
stack is 8K where as the IRQ stack is 4K.  We may want to see which IRQ 
stack call is the worst, and not compare it to the thread stack call.

-- Steve

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