summaryrefslogtreecommitdiff
path: root/include/linux/flex_array.h
AgeCommit message (Expand)Author
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman
2017-03-29Documentation: Add flexible-arrays.rst to the documentation treesayli karnik
2014-01-21reciprocal_divide: update/correction of the algorithmHannes Frederic Sowa
2011-05-26flex_array: avoid divisions when accessing elementsJesse Gross
2011-04-28flex_array: flex_array_prealloc takes a number of elements, not an endEric Paris
2010-11-30flex_array: fix flex_array_put_ptr macro to be valid CEric Paris
2010-08-09flex_array: add helpers to get and put to make pointers easy to useEric Paris
2009-09-22flex_array: introduce DEFINE_FLEX_ARRAYDavid Rientjes
2009-09-22flex_array: add flex_array_shrink functionDavid Rientjes
2009-09-22flex_array: add flex_array_clear functionDavid Rientjes
2009-08-26flex_array: convert element_nr formals to unsignedDavid Rientjes
2009-08-26flex_array: declare parts member to have incomplete typeDavid Rientjes
2009-07-29lib: flexible array implementationDave Hansen
generated by cgit v1.2.3 (git 2.46.0) at 2026-07-17 23:33:38 +0000
; Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2014-06-10decode_stacktrace: make stack dump output useful againSasha Levin Right now when people try to report issues in the kernel they send stack dumps to eachother, which looks something like this: [ 6.906437] [<ffffffff811f0e90>] ? backtrace_test_irq_callback+0x20/0x20 [ 6.907121] [<ffffffff84388ce8>] dump_stack+0x52/0x7f [ 6.907640] [<ffffffff811f0ec8>] backtrace_regression_test+0x38/0x110 [ 6.908281] [<ffffffff813596a0>] ? proc_create_data+0xa0/0xd0 [ 6.908870] [<ffffffff870a8040>] ? proc_modules_init+0x22/0x22 [ 6.909480] [<ffffffff810020c2>] do_one_initcall+0xc2/0x1e0 [...] However, most of the text you get is pure garbage. The only useful thing above is the function name. Due to the amount of different kernel code versions and various configurations being used, the kernel address and the offset into the function are not really helpful in determining where the problem actually occured. Too often the result of someone looking at a stack dump is asking the person who sent it for a translation for one or more 'addr2line' translations. Which slows down the entire process of debugging the issue (and really annoying). The decode_stacktrace script is an attempt to make the output more useful and easy to work with by translating all kernel addresses in the stack dump into line numbers. Which means that the stack dump would look like this: [ 635.148361] dump_stack (lib/dump_stack.c:52) [ 635.149127] warn_slowpath_common (kernel/panic.c:418) [ 635.150214] warn_slowpath_null (kernel/panic.c:453) [ 635.151031] _oalloc_pages_slowpath+0x6a/0x7d0 [ 635.152171] ? zone_watermark_ok (mm/page_alloc.c:1728) [ 635.152988] ? get_page_from_freelist (mm/page_alloc.c:1939) [ 635.154766] __alloc_pages_nodemask (mm/page_alloc.c:2766) It's pretty obvious why this is better than the previous stack dump before. Usage is pretty simple: ./decode_stacktrace.sh [vmlinux] [base path] Where vmlinux is the vmlinux to extract line numbers from and base path is the path that points to the root of the build tree, for example: ./decode_stacktrace.sh vmlinux /home/sasha/linux/ < input.log > output.log The stack trace should be piped through it (I, for example, just pipe the output of the serial console of my KVM test box through it). Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>