18 Sep, 2020

1 commit

  • Currently the callback passed to arch_stack_walk() has an argument called
    reliable passed to it to indicate if the stack entry is reliable, a comment
    says that this is used by some printk() consumers. However in the current
    kernel none of the arch_stack_walk() implementations ever set this flag to
    true and the only callback implementation we have is in the generic
    stacktrace code which ignores the flag. It therefore appears that this
    flag is redundant so we can simplify and clarify things by removing it.

    Signed-off-by: Mark Brown
    Reviewed-by: Miroslav Benes
    Link: https://lore.kernel.org/r/20200914153409.25097-2-broonie@kernel.org
    Signed-off-by: Will Deacon

    Mark Brown
     

13 Aug, 2020

1 commit

  • Add helpers to wrap the get_fs/set_fs magic for undoing any damange done
    by set_fs(KERNEL_DS). There is no real functional benefit, but this
    documents the intent of these calls better, and will allow stubbing the
    functions out easily for kernels builds that do not allow address space
    overrides in the future.

    [hch@lst.de: drop two incorrect hunks, fix a commit log typo]
    Link: http://lkml.kernel.org/r/20200714105505.935079-6-hch@lst.de

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Acked-by: Linus Torvalds
    Acked-by: Mark Rutland
    Acked-by: Greentime Hu
    Acked-by: Geert Uytterhoeven
    Cc: Nick Hu
    Cc: Vincent Chen
    Cc: Paul Walmsley
    Cc: Palmer Dabbelt
    Link: http://lkml.kernel.org/r/20200710135706.537715-6-hch@lst.de
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     

11 Nov, 2019

1 commit

  • My commit b0c51f158455 ("stacktrace: Don't skip first entry on
    noncurrent tasks") adds one or zero to skipnr by "!!(current == tsk)".

    But the C99 standard says:

    The == (equal to) and != (not equal to) operators are
    ...
    Each of the operators yields 1 if the specified relation is true and 0
    if it is false.

    So there is no need to prepend the above expression by "!!" -- remove it.

    Reported-by: Joe Perches
    Signed-off-by: Jiri Slaby
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: https://lkml.kernel.org/r/20191111092647.27419-1-jslaby@suse.cz
    Signed-off-by: Ingo Molnar

    Jiri Slaby
     

05 Nov, 2019

1 commit

  • When doing cat /proc//stack, the output is missing the first entry.
    When the current code walks the stack starting in stack_trace_save_tsk,
    it skips all scheduler functions (that's OK) plus one more function. But
    this one function should be skipped only for the 'current' task as it is
    stack_trace_save_tsk proper.

    The original code (before the common infrastructure) skipped one
    function only for the 'current' task -- see save_stack_trace_tsk before
    3599fe12a125. So do so also in the new infrastructure now.

    Fixes: 214d8ca6ee85 ("stacktrace: Provide common infrastructure")
    Signed-off-by: Jiri Slaby
    Signed-off-by: Thomas Gleixner
    Tested-by: Michal Suchanek
    Acked-by: Josh Poimboeuf
    Link: https://lkml.kernel.org/r/20191030072545.19462-1-jslaby@suse.cz

    Jiri Slaby
     

25 Jul, 2019

1 commit

  • Make it clear to humans and to the compiler that the stack trace
    ('entries') arguments are not modified.

    Signed-off-by: Bart Van Assche
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: Waiman Long
    Cc: Will Deacon
    Link: https://lkml.kernel.org/r/20190722182443.216015-3-bvanassche@acm.org
    Signed-off-by: Ingo Molnar

    Bart Van Assche
     

18 Jul, 2019

1 commit

  • When walking userspace stacks, USER_DS needs to be set, otherwise
    access_ok() will not function as expected.

    Reported-by: Vegard Nossum
    Reported-by: Eiichi Tsukata
    Signed-off-by: Peter Zijlstra (Intel)
    Signed-off-by: Thomas Gleixner
    Tested-by: Vegard Nossum
    Reviewed-by: Joel Fernandes (Google)
    Link: https://lkml.kernel.org/r/20190718085754.GM3402@hirez.programming.kicks-ass.net

    Peter Zijlstra
     

12 Jul, 2019

1 commit

  • Pull livepatching updates from Jiri Kosina:

    - stacktrace handling improvements from Miroslav benes

    - debug output improvements from Petr Mladek

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching:
    livepatch: Remove duplicate warning about missing reliable stacktrace support
    Revert "livepatch: Remove reliable stacktrace check in klp_try_switch_task()"
    stacktrace: Remove weak version of save_stack_trace_tsk_reliable()
    livepatch: Use static buffer for debugging messages under rq lock
    livepatch: Remove stale kobj_added entries from kernel-doc descriptions

    Linus Torvalds
     

03 Jul, 2019

1 commit

  • !current->mm is not a reliable indicator for kernel threads as they might
    temporarily use a user mm. Check for PF_KTHREAD instead.

    Signed-off-by: Thomas Gleixner
    Acked-by: Mark Rutland
    Cc: Josh Poimboeuf
    Cc: Peter Zijlstra
    Cc: Steven Rostedt
    Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1907021750100.1802@nanos.tec.linutronix.de

    Thomas Gleixner
     

20 Jun, 2019

1 commit

  • Recent rework of stack trace infrastructure introduced a new set of
    helpers for common stack trace operations (commit e9b98e162aa5
    ("stacktrace: Provide helpers for common stack trace operations") and
    related). As a result, save_stack_trace_tsk_reliable() is not directly
    called anywhere. Livepatch, currently the only user of the reliable
    stack trace feature, now calls stack_trace_save_tsk_reliable().

    When CONFIG_HAVE_RELIABLE_STACKTRACE is set and depending on
    CONFIG_ARCH_STACKWALK, stack_trace_save_tsk_reliable() calls either
    arch_stack_walk_reliable() or mentioned save_stack_trace_tsk_reliable().
    x86_64 defines the former, ppc64le the latter. All other architectures
    do not have HAVE_RELIABLE_STACKTRACE and include/linux/stacktrace.h
    defines -ENOSYS returning version for them.

    In short, stack_trace_save_tsk_reliable() returning -ENOSYS defined in
    include/linux/stacktrace.h serves the same purpose as the old weak
    version of save_stack_trace_tsk_reliable() which is therefore no longer
    needed.

    Signed-off-by: Miroslav Benes
    Acked-by: Josh Poimboeuf
    Reviewed-by: Thomas Gleixner
    Reviewed-by: Kamalesh Babulal
    Signed-off-by: Petr Mladek

    Miroslav Benes
     

03 Jun, 2019

1 commit


21 May, 2019

1 commit

  • Add SPDX license identifiers to all files which:

    - Have no license information of any form

    - Have EXPORT_.*_SYMBOL_GPL inside which was used in the
    initial scan/conversion to ignore the file

    These files fall under the project license, GPL v2 only. The resulting SPDX
    license identifier is:

    GPL-2.0-only

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

19 May, 2019

1 commit

  • Miroslav reported that the livepatch self-tests were failing, specifically
    a case in which the consistency model ensures that a current executing
    function is not allowed to be patched, "TEST: busy target module".

    Recent renovations of stack_trace_save_tsk_reliable() left it returning
    only an -ERRNO success indication in some configuration combinations:

    klp_check_stack()
    ret = stack_trace_save_tsk_reliable()
    #ifdef CONFIG_ARCH_STACKWALK && CONFIG_HAVE_RELIABLE_STACKTRACE
    stack_trace_save_tsk_reliable()
    ret = arch_stack_walk_reliable()
    return 0
    return -EINVAL
    ...
    return ret;
    ...
    if (ret < 0)
    /* stack_trace_save_tsk_reliable error */
    nr_entries = ret; << 0

    Previously (and currently for !CONFIG_ARCH_STACKWALK &&
    CONFIG_HAVE_RELIABLE_STACKTRACE) stack_trace_save_tsk_reliable() returned
    the number of entries that it consumed in the passed storage array.

    In the case of the above config and trace, be sure to return the
    stacktrace_cookie.len on stack_trace_save_tsk_reliable() success.

    Fixes: 25e39e32b0a3f ("livepatch: Simplify stack trace retrieval")
    Reported-by: Miroslav Benes
    Signed-off-by: Joe Lawrence
    Signed-off-by: Thomas Gleixner
    Reviewed-by: Kamalesh Babulal
    Acked-by: Josh Poimboeuf
    Cc: live-patching@vger.kernel.org
    Cc: jikos@kernel.org
    Cc: pmladek@suse.com
    Link: https://lkml.kernel.org/r/20190517185117.24642-1-joe.lawrence@redhat.com

    Joe Lawrence
     

29 Apr, 2019

3 commits

  • All architectures which support stacktrace carry duplicated code and
    do the stack storage and filtering at the architecture side.

    Provide a consolidated interface with a callback function for consuming the
    stack entries provided by the architecture specific stack walker. This
    removes lots of duplicated code and allows to implement better filtering
    than 'skip number of entries' in the future without touching any
    architecture specific code.

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Josh Poimboeuf
    Cc: Andy Lutomirski
    Cc: linux-arch@vger.kernel.org
    Cc: Steven Rostedt
    Cc: Alexander Potapenko
    Cc: Alexey Dobriyan
    Cc: Andrew Morton
    Cc: Christoph Lameter
    Cc: Pekka Enberg
    Cc: linux-mm@kvack.org
    Cc: David Rientjes
    Cc: Catalin Marinas
    Cc: Dmitry Vyukov
    Cc: Andrey Ryabinin
    Cc: kasan-dev@googlegroups.com
    Cc: Mike Rapoport
    Cc: Akinobu Mita
    Cc: Christoph Hellwig
    Cc: iommu@lists.linux-foundation.org
    Cc: Robin Murphy
    Cc: Marek Szyprowski
    Cc: Johannes Thumshirn
    Cc: David Sterba
    Cc: Chris Mason
    Cc: Josef Bacik
    Cc: linux-btrfs@vger.kernel.org
    Cc: dm-devel@redhat.com
    Cc: Mike Snitzer
    Cc: Alasdair Kergon
    Cc: Daniel Vetter
    Cc: intel-gfx@lists.freedesktop.org
    Cc: Joonas Lahtinen
    Cc: Maarten Lankhorst
    Cc: dri-devel@lists.freedesktop.org
    Cc: David Airlie
    Cc: Jani Nikula
    Cc: Rodrigo Vivi
    Cc: Tom Zanussi
    Cc: Miroslav Benes
    Link: https://lkml.kernel.org/r/20190425094803.713568606@linutronix.de

    Thomas Gleixner
     
  • No more users of the struct stack_trace based interfaces. Remove them.

    Remove the macro stubs for !CONFIG_STACKTRACE as well as they are pointless
    because the storage on the call sites is conditional on CONFIG_STACKTRACE
    already. No point to be 'smart'.

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Josh Poimboeuf
    Cc: Andy Lutomirski
    Cc: Steven Rostedt
    Cc: Alexander Potapenko
    Cc: Alexey Dobriyan
    Cc: Andrew Morton
    Cc: Christoph Lameter
    Cc: Pekka Enberg
    Cc: linux-mm@kvack.org
    Cc: David Rientjes
    Cc: Catalin Marinas
    Cc: Dmitry Vyukov
    Cc: Andrey Ryabinin
    Cc: kasan-dev@googlegroups.com
    Cc: Mike Rapoport
    Cc: Akinobu Mita
    Cc: Christoph Hellwig
    Cc: iommu@lists.linux-foundation.org
    Cc: Robin Murphy
    Cc: Marek Szyprowski
    Cc: Johannes Thumshirn
    Cc: David Sterba
    Cc: Chris Mason
    Cc: Josef Bacik
    Cc: linux-btrfs@vger.kernel.org
    Cc: dm-devel@redhat.com
    Cc: Mike Snitzer
    Cc: Alasdair Kergon
    Cc: Daniel Vetter
    Cc: intel-gfx@lists.freedesktop.org
    Cc: Joonas Lahtinen
    Cc: Maarten Lankhorst
    Cc: dri-devel@lists.freedesktop.org
    Cc: David Airlie
    Cc: Jani Nikula
    Cc: Rodrigo Vivi
    Cc: Tom Zanussi
    Cc: Miroslav Benes
    Cc: linux-arch@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190425094803.524796783@linutronix.de

    Thomas Gleixner
     
  • All operations with stack traces are based on struct stack_trace. That's a
    horrible construct as the struct is a kitchen sink for input and
    output. Quite some usage sites embed it into their own data structures
    which creates weird indirections.

    There is absolutely no point in doing so. For all use cases a storage array
    and the number of valid stack trace entries in the array is sufficient.

    Provide helper functions which avoid the struct stack_trace indirection so
    the usage sites can be cleaned up.

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Josh Poimboeuf
    Cc: Andy Lutomirski
    Cc: Steven Rostedt
    Cc: Alexander Potapenko
    Cc: Alexey Dobriyan
    Cc: Andrew Morton
    Cc: Christoph Lameter
    Cc: Pekka Enberg
    Cc: linux-mm@kvack.org
    Cc: David Rientjes
    Cc: Catalin Marinas
    Cc: Dmitry Vyukov
    Cc: Andrey Ryabinin
    Cc: kasan-dev@googlegroups.com
    Cc: Mike Rapoport
    Cc: Akinobu Mita
    Cc: Christoph Hellwig
    Cc: iommu@lists.linux-foundation.org
    Cc: Robin Murphy
    Cc: Marek Szyprowski
    Cc: Johannes Thumshirn
    Cc: David Sterba
    Cc: Chris Mason
    Cc: Josef Bacik
    Cc: linux-btrfs@vger.kernel.org
    Cc: dm-devel@redhat.com
    Cc: Mike Snitzer
    Cc: Alasdair Kergon
    Cc: Daniel Vetter
    Cc: intel-gfx@lists.freedesktop.org
    Cc: Joonas Lahtinen
    Cc: Maarten Lankhorst
    Cc: dri-devel@lists.freedesktop.org
    Cc: David Airlie
    Cc: Jani Nikula
    Cc: Rodrigo Vivi
    Cc: Tom Zanussi
    Cc: Miroslav Benes
    Cc: linux-arch@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190425094801.324810708@linutronix.de

    Thomas Gleixner
     

08 Mar, 2017

1 commit

  • For live patching and possibly other use cases, a stack trace is only
    useful if it can be assured that it's completely reliable. Add a new
    save_stack_trace_tsk_reliable() function to achieve that.

    Note that if the target task isn't the current task, and the target task
    is allowed to run, then it could be writing the stack while the unwinder
    is reading it, resulting in possible corruption. So the caller of
    save_stack_trace_tsk_reliable() must ensure that the task is either
    'current' or inactive.

    save_stack_trace_tsk_reliable() relies on the x86 unwinder's detection
    of pt_regs on the stack. If the pt_regs are not user-mode registers
    from a syscall, then they indicate an in-kernel interrupt or exception
    (e.g. preemption or a page fault), in which case the stack is considered
    unreliable due to the nature of frame pointers.

    It also relies on the x86 unwinder's detection of other issues, such as:

    - corrupted stack data
    - stack grows the wrong way
    - stack walk doesn't reach the bottom
    - user didn't provide a large enough entries array

    Such issues are reported by checking unwind_error() and !unwind_done().

    Also add CONFIG_HAVE_RELIABLE_STACKTRACE so arch-independent code can
    determine at build time whether the function is implemented.

    Signed-off-by: Josh Poimboeuf
    Reviewed-by: Miroslav Benes
    Acked-by: Ingo Molnar # for the x86 changes
    Signed-off-by: Jiri Kosina

    Josh Poimboeuf
     

08 Feb, 2017

1 commit

  • Since KERN_CONT became meaningful again, lockdep stack traces have had
    annoying extra newlines, like this:

    [ 5.561122] -> #1 (B){+.+...}:
    [ 5.561528]
    [ 5.561532] [] lock_acquire+0xc3/0x210
    [ 5.562178]
    [ 5.562181] [] mutex_lock_nested+0x74/0x6d0
    [ 5.562861]
    [ 5.562880] [] init_btrfs_fs+0x21/0x196 [btrfs]
    [ 5.563717]
    [ 5.563721] [] do_one_initcall+0x52/0x1b0
    [ 5.564554]
    [ 5.564559] [] do_init_module+0x5f/0x209
    [ 5.565357]
    [ 5.565361] [] load_module+0x218d/0x2b80
    [ 5.566020]
    [ 5.566021] [] SyS_finit_module+0xeb/0x120
    [ 5.566694]
    [ 5.566696] [] entry_SYSCALL_64_fastpath+0x1f/0xc2

    That's happening because each printk() call now gets printed on its own
    line, and we do a separate call to print the spaces before the symbol.
    Fix it by doing the printk() directly instead of using the
    print_ip_sym() helper.

    Additionally, the symbol address isn't very helpful, so let's get rid of
    that, too. The final result looks like this:

    [ 5.194518] -> #1 (B){+.+...}:
    [ 5.195002] lock_acquire+0xc3/0x210
    [ 5.195439] mutex_lock_nested+0x74/0x6d0
    [ 5.196491] do_one_initcall+0x52/0x1b0
    [ 5.196939] do_init_module+0x5f/0x209
    [ 5.197355] load_module+0x218d/0x2b80
    [ 5.197792] SyS_finit_module+0xeb/0x120
    [ 5.198251] entry_SYSCALL_64_fastpath+0x1f/0xc2

    Suggested-by: Linus Torvalds
    Signed-off-by: Omar Sandoval
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: kernel-team@fb.com
    Fixes: 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines")
    Link: http://lkml.kernel.org/r/43b4e114724b2bdb0308fa86cb33aa07d3d67fad.1486510315.git.osandov@fb.com
    Signed-off-by: Ingo Molnar

    Omar Sandoval
     

14 Dec, 2014

1 commit

  • Current stacktrace only have the function for console output. page_owner
    that will be introduced in following patch needs to print the output of
    stacktrace into the buffer for our own output format so so new function,
    snprint_stack_trace(), is needed.

    Signed-off-by: Joonsoo Kim
    Cc: Mel Gorman
    Cc: Johannes Weiner
    Cc: Minchan Kim
    Cc: Dave Hansen
    Cc: Michal Nazarewicz
    Cc: Jungsoo Son
    Cc: Ingo Molnar
    Cc: Joonsoo Kim
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Joonsoo Kim
     

31 Oct, 2011

1 commit

  • The changed files were only including linux/module.h for the
    EXPORT_SYMBOL infrastructure, and nothing else. Revector them
    onto the isolated export header for faster compile times.

    Nothing to see here but a whole lot of instances of:

    -#include
    +#include

    This commit is only changing the kernel dir; next targets
    will probably be mm, fs, the arch dirs, etc.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

15 Jun, 2011

1 commit

  • Add weak symbol of save_stack_trace_regs() as same as
    save_stack_trace_tsk() since that is not implemented
    except x86 yet.

    Signed-off-by: Masami Hiramatsu
    Cc: Frederic Weisbecker
    Cc: yrl.pp-manager.tt@hitachi.com
    Cc: Peter Zijlstra
    Cc: Namhyung Kim
    Link: http://lkml.kernel.org/r/20110608070927.17777.37895.stgit@fedora15
    Signed-off-by: Steven Rostedt

    Masami Hiramatsu
     

25 Dec, 2008

1 commit


30 Jun, 2008

1 commit


13 Jun, 2008

1 commit


24 May, 2008

1 commit

  • This patch makes the stacktrace printout code \warn when the entries
    pointer is unset rather than crashing when trying to access it in an
    attempt to make it a bit more robust.

    I was saving a stacktrace into an skb and forgot to copy it across skb
    copies... I have since fixed the code, but it would have been easier
    had the kernel not crashed in an interrupt.

    Signed-off-by: Johannes Berg
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Johannes Berg
     

04 Jul, 2006

1 commit