[patch] add /proc/pid/stack to dump task's stack trace - Kernel

This is a discussion on [patch] add /proc/pid/stack to dump task's stack trace - Kernel ; On Sat, Nov 08, 2008 at 01:10:54PM +0100, Ingo Molnar wrote: > Sidenote: it would still be nice if the procfs folks converted the > old-style code there to the new seqfile APIs, before requiring > everyone _else_ to follow ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 29 of 29

Thread: [patch] add /proc/pid/stack to dump task's stack trace

  1. Re: [patch] add /proc/pid/stack to dump task's stack trace

    On Sat, Nov 08, 2008 at 01:10:54PM +0100, Ingo Molnar wrote:
    > Sidenote: it would still be nice if the procfs folks converted the
    > old-style code there to the new seqfile APIs, before requiring
    > everyone _else_ to follow those guidelines?


    For every existing non seqfile /proc file, there may be (and was demonstrated)
    some userspace which is doing pread(2) on it and seqfiles don't support pread
    currently. Obviously, no such userspace exist for /proc/*/stack.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [patch] add /proc/pid/stack to dump task's stack trace


    * Alexey Dobriyan wrote:

    > On Sat, Nov 08, 2008 at 01:10:54PM +0100, Ingo Molnar wrote:
    > > Sidenote: it would still be nice if the procfs folks converted the
    > > old-style code there to the new seqfile APIs, before requiring
    > > everyone _else_ to follow those guidelines?

    >
    > For every existing non seqfile /proc file, there may be (and was
    > demonstrated) some userspace which is doing pread(2) on it and
    > seqfiles don't support pread currently. Obviously, no such userspace
    > exist for /proc/*/stack.


    ok, i then dont understand why we are advocating seqfile use, while
    seqfiles are inferior replacements in certain aspects (no pread(2)
    support). Adding pread(2) support would remove all doubt, and it could
    be converted all across the spectrum, eliminating any confusion about
    which facility to use, right?

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

  3. Re: [patch] add /proc/pid/stack to dump task's stack trace

    On Fri, 7 Nov 2008 10:29:02 +0100
    Ingo Molnar wrote:

    > > I guess the 0400 mode on that file will suffice...

    >
    > correct, 0400 is used already in the present patch:
    >
    > phoenix:~> cat /proc/1/stack
    > cat: /proc/1/stack: Permission denied
    >
    > but that is _not_ enough, it should be narrowed even more, to the
    > boundaries that i pointed out in my first review feedback mail, and
    > which is not implemented yet:
    >
    > 1) only root should be allowed to do this - i.e. file needs to be
    > root-owned.
    >
    > 2) there also needs to be a .config entry for folks to be able to
    > turn it off altogether - just like folks can turn off sysrq-t
    > dumping via the .config.


    Doing the above is desirable for another reason: given our rather
    erratic history with the stack backtracer, this /proc file is possibly
    a convenient way of oopsing the kernel, sending of off into la-la-land, etc.

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

  4. Re: [patch] add /proc/pid/stack to dump task's stack trace


    * Andrew Morton wrote:

    > On Fri, 7 Nov 2008 10:29:02 +0100
    > Ingo Molnar wrote:
    >
    > > > I guess the 0400 mode on that file will suffice...

    > >
    > > correct, 0400 is used already in the present patch:
    > >
    > > phoenix:~> cat /proc/1/stack
    > > cat: /proc/1/stack: Permission denied
    > >
    > > but that is _not_ enough, it should be narrowed even more, to the
    > > boundaries that i pointed out in my first review feedback mail, and
    > > which is not implemented yet:
    > >
    > > 1) only root should be allowed to do this - i.e. file needs to be
    > > root-owned.
    > >
    > > 2) there also needs to be a .config entry for folks to be able to
    > > turn it off altogether - just like folks can turn off sysrq-t
    > > dumping via the .config.

    >
    > Doing the above is desirable for another reason: given our rather
    > erratic history with the stack backtracer, this /proc file is
    > possibly a convenient way of oopsing the kernel, sending of off into
    > la-la-land, etc.


    the stack tracer is rock-solid on x86 since Arjan started cleaning up
    the backtracing mess which we indeed had in x86 for years:

    - adding frame-pointer support to 64-bit to improve the
    quality of stack-traces

    - eliminating the broken and fragile dwarf2-unwinder

    - expanding the use of the generic stacktrace infrastructure to
    lockdep, ftrace and other areas of code

    if you know about any remaining fragility please holler, we havent had
    a backtracer induced oops for a long time :-)

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

  5. Re: [patch] add /proc/pid/stack to dump task's stack trace

    On Fri, Nov 07, 2008 at 10:03:04AM +0100, Ingo Molnar wrote:
    >
    > btw., the feature works beautifully:
    >
    > task sleeping/blocked:
    >
    > # cat /proc/1/stack
    > [] do_select+0x51a/0x582
    > [] core_sys_select+0x17c/0x218
    > [] sys_select+0x99/0xc1
    > [] system_call_fastpath+0x16/0x1b
    > [] 0xffffffffffffffff
    >
    > task running on this CPU:
    >
    > # cat /proc/self/stack
    > [] save_stack_trace_tsk+0x26/0x44
    > [] proc_pid_stack+0x6e/0xd3
    > [] proc_info_read+0x68/0xba
    > [] vfs_read+0xa9/0xe3
    > [] sys_read+0x4c/0x73
    > [] system_call_fastpath+0x16/0x1b
    > [] 0xffffffffffffffff
    >
    > task running on another CPU in user-space:
    >
    > # cat /proc/18579/stack
    > [] 0xffffffffffffffff


    so this file provides view of _kernel_ stack only?
    shouldn't it be named kernel-stack then?

    > task running on another CPU in kernel-space:
    >
    > # cat /proc/18579/stack
    > [] audit_syscall_exit+0x9c/0xed
    > [] syscall_trace_leave+0x94/0xbb
    > [] 0xffffffffffffffff
    >
    > Ingo
    > --

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

  6. Re: [patch] add /proc/pid/stack to dump task's stack trace

    On Tue, Nov 11, 2008 at 01:25:36PM +0100, Marcin Slusarz wrote:
    > On Fri, Nov 07, 2008 at 10:03:04AM +0100, Ingo Molnar wrote:
    > >
    > > btw., the feature works beautifully:
    > >
    > > task sleeping/blocked:
    > >
    > > # cat /proc/1/stack
    > > [] do_select+0x51a/0x582
    > > [] core_sys_select+0x17c/0x218
    > > [] sys_select+0x99/0xc1
    > > [] system_call_fastpath+0x16/0x1b
    > > [] 0xffffffffffffffff
    > >
    > > task running on this CPU:
    > >
    > > # cat /proc/self/stack
    > > [] save_stack_trace_tsk+0x26/0x44
    > > [] proc_pid_stack+0x6e/0xd3
    > > [] proc_info_read+0x68/0xba
    > > [] vfs_read+0xa9/0xe3
    > > [] sys_read+0x4c/0x73
    > > [] system_call_fastpath+0x16/0x1b
    > > [] 0xffffffffffffffff
    > >
    > > task running on another CPU in user-space:
    > >
    > > # cat /proc/18579/stack
    > > [] 0xffffffffffffffff

    >
    > so this file provides view of _kernel_ stack only?


    Of course!

    > shouldn't it be named kernel-stack then?
    >
    > > task running on another CPU in kernel-space:
    > >
    > > # cat /proc/18579/stack
    > > [] audit_syscall_exit+0x9c/0xed
    > > [] syscall_trace_leave+0x94/0xbb
    > > [] 0xffffffffffffffff

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

  7. Re: [patch] add /proc/pid/stack to dump task's stack trace


    * Marcin Slusarz wrote:

    > On Fri, Nov 07, 2008 at 10:03:04AM +0100, Ingo Molnar wrote:
    > >
    > > btw., the feature works beautifully:
    > >
    > > task sleeping/blocked:
    > >
    > > # cat /proc/1/stack
    > > [] do_select+0x51a/0x582
    > > [] core_sys_select+0x17c/0x218
    > > [] sys_select+0x99/0xc1
    > > [] system_call_fastpath+0x16/0x1b
    > > [] 0xffffffffffffffff
    > >
    > > task running on this CPU:
    > >
    > > # cat /proc/self/stack
    > > [] save_stack_trace_tsk+0x26/0x44
    > > [] proc_pid_stack+0x6e/0xd3
    > > [] proc_info_read+0x68/0xba
    > > [] vfs_read+0xa9/0xe3
    > > [] sys_read+0x4c/0x73
    > > [] system_call_fastpath+0x16/0x1b
    > > [] 0xffffffffffffffff
    > >
    > > task running on another CPU in user-space:
    > >
    > > # cat /proc/18579/stack
    > > [] 0xffffffffffffffff

    >
    > so this file provides view of _kernel_ stack only?
    > shouldn't it be named kernel-stack then?


    it prints the kernel stack right now, but i'd not restrict it to the
    kernel stack conceptually: i think we could eventually expand it to
    print the user-space portion of the stack as well. (in the case when
    user-space is built with frame pointers) We've got code for that in
    the kernel already. It would be an easy one-stop-shop for full-range.

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

  8. Re: [patch] add /proc/pid/stack to dump task's stack trace

    Ingo Molnar writes:
    > > > # cat /proc/18579/stack
    > > > [] 0xffffffffffffffff

    > >
    > > so this file provides view of _kernel_ stack only?
    > > shouldn't it be named kernel-stack then?

    >
    > it prints the kernel stack right now, but i'd not restrict it to the
    > kernel stack conceptually: i think we could eventually expand it to
    > print the user-space portion of the stack as well. (in the case when
    > user-space is built with frame pointers) We've got code for that in
    > the kernel already. It would be an easy one-stop-shop for full-range.


    That would be quite fragile given the fact that user-space
    only has to follow standard ABIs at specific points like
    calls to standard library functions. In between, anything
    can, and does, happen.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [patch] add /proc/pid/stack to dump task's stack trace


    * Mikael Pettersson wrote:

    > Ingo Molnar writes:
    > > > > # cat /proc/18579/stack
    > > > > [] 0xffffffffffffffff
    > > >
    > > > so this file provides view of _kernel_ stack only?
    > > > shouldn't it be named kernel-stack then?

    > >
    > > it prints the kernel stack right now, but i'd not restrict it to
    > > the kernel stack conceptually: i think we could eventually expand
    > > it to print the user-space portion of the stack as well. (in the
    > > case when user-space is built with frame pointers) We've got code
    > > for that in the kernel already. It would be an easy one-stop-shop
    > > for full-range.

    >
    > That would be quite fragile given the fact that user-space only has
    > to follow standard ABIs at specific points like calls to standard
    > library functions. In between, anything can, and does, happen.


    it's not fragile to robustly walk the userspace stack. The result
    might not always be meaningful of course.

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

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2