lkml.org 
[lkml]   [2015]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC 2/3] arm64: refactor save_stack_trace()
    From
    Date
    On Jul 21, 2015, at 7:26 PM, AKASHI Takahiro wrote:
    > On 07/21/2015 08:53 AM, AKASHI Takahiro wrote:
    >> Hi
    >>
    >> So i don't have to repost my patch here. Please use the original
    >> commit log message[1/3] as is.
    >> But please keep in mind that there is still an issue that I mentioned
    >> in the cover letter; 'Size' field is inaccurate.
    >> <reported size> = <its own dynamic local variables>
    >> + <child's local variables>
    >> and
    >> <real size> = <reported size> + <its local variables>
    >> - <child's local variables>
    >> where "dynamic" means, for example, a variable allocated like the below:
    >> int foo(int num) {
    >> int array[num];
    >> ...
    >> }
    >> (See more details in my ascii art.)
    >>
    >> Such usage is seldom seen in the kernel, and <reported size> is
    >> likely equal to <child's local variables>. In other words, we will
    >> see one-line *displacement* in most cases.
    >
    > Well, I have a quick fix now, but it looks ugly.

    AFAIU, stack_max_size would be more accurate if a separate stack
    is introduced for interrupt context. However, it might be unnecessary
    at this point due to complexity.

    > In addition, I found another issue; With function_graph tracer,
    > the output is like:
    > # cat /sys/kernel/tracing/stack_trace
    > Depth Size Location (78 entries)
    > ----- ---- --------
    > 0) 6184 32 update_min_vruntime+0x14/0x74
    > 1) 6152 48 update_curr+0x6c/0x150
    > 2) 6104 128 enqueue_task_fair+0x2f4/0xb9c
    > 3) 5976 48 enqueue_task+0x48/0x90
    > ...
    > 18) 5160 112 hrtimer_interrupt+0xa0/0x214
    > 19) 5048 32 arch_timer_handler_phys+0x38/0x48
    > 20) 5016 0 ftrace_graph_caller+0x2c/0x30
    > 21) 5016 64 ftrace_graph_caller+0x2c/0x30
    > 22) 4952 32 ftrace_graph_caller+0x2c/0x30
    > 23) 4920 64 ftrace_graph_caller+0x2c/0x30
    > ...
    >
    > Since, with function_graph tracer, we modify LR register in a stack frame
    > when we enter into a function, we have to manage such special cases
    > in save_stack_trace() or check_stack() as x86 does in
    > print_ftrace_graph_addr().

    I should have run it with function_graph. The issue is reproduced easily
    on my environment. I don't see other issues yet when enabling other tracers.

    Best Regards
    Jungseok Lee


    \
     
     \ /
      Last update: 2015-07-21 16:41    [W:9.108 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site