[lkml]   [2010]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [tip:x86/irq] x86: Always use irq stacks
    On Wed, 2010-07-14 at 17:47 +0200, Christoph Hellwig wrote:

    > > So you're saying, that the problem appears when
    > > CONFIG_FUNCTION_GRAPH_TRACER is enabled w/o being used and that it
    > > exists prior to your patches with irq stacks and 8k stack size, but
    > > works with 4k stacks. That's definitely more than odd.
    > No, the problem does not show up with 8k stack size without irqstacks,
    > and does not show up with 4k stacks with irq stacks, but does show up
    > with 8k stacks with irqstacks as long as CONFIG_FUNCTION_GRAPH_TRACER is
    > enabled. Just disabling it in Ingo's example config makes it work,
    > and enabling it in my usual test configs makes the boot fail with
    > similar messages to the one Ingo sees.

    Examining the difference between 32bit and 64bit (where it only triggers
    for 32bit) I found this:

    In arch/x86/kernel/dumpstack_64.c:

    tinfo = task_thread_info(task);
    bp = ops->walk_stack(tinfo, stack, bp, ops,
    data, estack_end, &graph);

    Note: tinfo here that is passed to walk_stack() is the actual thread
    info structure for the task.

    In arch/x86/kernel/dumpstack_32.c:

    context = (struct thread_info *)
    ((unsigned long)stack & (~(THREAD_SIZE - 1)));
    bp = ops->walk_stack(context, stack, bp, ops, data, NULL, &graph);

    Note: here, context (which ends up being tinfo) is just a bitmasking of
    the current stack. If the stack is the irqstack, then what is passed to
    walk_stack() is not the actual thread info structure.

    Note, if THREAD_SIZE is 8k and irqstacks are 4K then context is totally
    wrong here.

    Now for the reason that function graph noticed this:

    static const struct stacktrace_ops print_trace_ops = {
    .warning = print_trace_warning,
    .warning_symbol = print_trace_warning_symbol,
    .stack = print_trace_stack,
    .address = print_trace_address,
    .walk_stack = print_context_stack,

    Where walk_stack is print_context_stack:

    tinfo is pretty much ignored in print_context_stack, but when function
    graph is enabled we have:

    print_ftrace_graph_addr(addr, data, ops, tinfo, graph);

    Which actually plays with the tinfo structure. If tinfo is corrupted
    here, then we get the bug.

    -- Steve

     \ /
      Last update: 2010-07-23 16:17    [W:0.192 / U:5.268 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site