linux-kernel - Re: [PATCH v3 1/2] lib: stacklog_debug: Introduce helper tool for collecting and displaying stacktraces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241219092206.01354aca@gandalf.local.home>
Date: Thu, 19 Dec 2024 09:22:06 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: John Stultz <jstultz@...gle.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Alexander Potapenko
 <glider@...gle.com>, Andrey Konovalov <andreyknvl@...il.com>, Andrew Morton
 <akpm@...ux-foundation.org>, kernel-team@...roid.com
Subject: Re: [PATCH v3 1/2] lib: stacklog_debug: Introduce helper tool for
 collecting and displaying stacktraces

On Wed, 18 Dec 2024 22:06:05 -0800
John Stultz <jstultz@...gle.com> wrote:

> When debugging, its often useful to understand how a function is
> called and the different paths taken to get there. Usually
> dump_stack() can be used for this purpose. However there are a
> number of cases where a function is called very frequently,
> making dump_stack far too noisy to be useful.
> 
> This is a little debug tool that utilizes stackdepot to capture
> unique stack traces and store them in a circular buffer.
> 
> In the code, the developer adds: stacklog_debug_save() calls
> at points of interest (as they might with stack_dump()).
> 
> Then after running the kernel, the developer can dump the unique
> stack traces from the buffer via:
>    cat /sys/kernel/debug/stacklog_debug
> 
> This is pretty trivial, but I've had this hanging around for
> awhile and recently hit another case where it was helpful, so I
> figured it would be worth sending it out for feedback as to if
> others thought it would be useful enough to merge upstream or to
> possibly rework into stackdepot itself?

Have you looked at using ftrace?

You can even do histograms of stack traces from tracepoints (including
kprobe events).

Let's say we want to see all the calls to kmalloc:

 # echo 'hist:keys=common_stacktrace' > /sys/kernel/tracing/events/kmem/kmalloc/trigger
 # cat /sys/kernel/tracing/events/kmem/kmalloc/hist
# event histogram
#
# trigger info: hist:keys=common_stacktrace:vals=hitcount:sort=hitcount:size=2048 [active]
#

{ common_stacktrace:
         kmalloc_reserve+0xb3/0x100
         __alloc_skb+0xb1/0x160
         alloc_skb_with_frags+0x58/0x1d0
         sock_alloc_send_pskb+0x1db/0x250
         __ip_append_data+0x50d/0xf20
         ip_make_skb+0x142/0x200
         udp_sendmsg+0xaa5/0xc20
         __sock_sendmsg+0x6c/0xb0
         __sys_sendto+0x282/0x2f0
         __x64_sys_sendto+0x26/0x30
         do_syscall_64+0x8f/0x110
         entry_SYSCALL_64_after_hwframe+0x71/0x79
} hitcount:          1
{ common_stacktrace:
         __kvmalloc_node_noprof+0x45/0xd0
         file_tty_write+0xfb/0x340
         vfs_write+0x2fc/0x350
         ksys_write+0x8c/0x100
         do_syscall_64+0x8f/0x110
         entry_SYSCALL_64_after_hwframe+0x71/0x79
} hitcount:          1
{ common_stacktrace:
         __kmalloc_node_noprof+0x255/0x370
         __kvmalloc_node_noprof+0x45/0xd0
         seq_read_iter+0x21b/0x440
         seq_read+0x13e/0x170
         vfs_read+0xc2/0x310
         ksys_read+0x8c/0x100
         do_syscall_64+0x8f/0x110
         entry_SYSCALL_64_after_hwframe+0x71/0x79
} hitcount:          1
{ common_stacktrace:
         virtqueue_add+0x215/0xde0
         virtqueue_add_outbuf+0x3a/0x60
         start_xmit+0x45d/0x7f0
         dev_hard_start_xmit+0xcd/0x260
         sch_direct_xmit+0xdf/0x260
         __dev_queue_xmit+0xc91/0x1100
         ip_finish_output2+0x481/0x4f0
         __ip_queue_xmit+0x664/0x6f0
         __tcp_transmit_skb+0x899/0xa70
         tcp_write_xmit+0x885/0x11a0
         tcp_tsq_handler+0x97/0xc0
         tcp_tasklet_func+0xc9/0x130
         tasklet_action_common+0x136/0x410
         handle_softirqs+0x11e/0x3b0
         __irq_exit_rcu+0x69/0x110
         irq_exit_rcu+0xe/0x20
} hitcount:          1
{ common_stacktrace:
[..]
{ common_stacktrace:
         alloc_pipe_info+0x6a/0x220
         create_pipe_files+0x4a/0x200
         __do_pipe_flags+0x31/0xd0
         do_pipe2+0x4f/0xe0
         __x64_sys_pipe2+0x18/0x20
         do_syscall_64+0x8f/0x110
         entry_SYSCALL_64_after_hwframe+0x71/0x79
} hitcount:          4
{ common_stacktrace:
         __vmalloc_node_range_noprof+0x2a4/0x710
         vmalloc_noprof+0x45/0x50
         tracing_map_sort_entries+0x2b/0x3f0
         hist_show+0x18d/0x810
         seq_read_iter+0x1a6/0x440
         seq_read+0x13e/0x170
         vfs_read+0xc2/0x310
         ksys_read+0x8c/0x100
         do_syscall_64+0x8f/0x110
         entry_SYSCALL_64_after_hwframe+0x71/0x79
} hitcount:          4
{ common_stacktrace:
         tracing_map_sort_entries+0xa5/0x3f0
         hist_show+0x18d/0x810
         seq_read_iter+0x1a6/0x440
         seq_read+0x13e/0x170
         vfs_read+0xc2/0x310
         ksys_read+0x8c/0x100
         do_syscall_64+0x8f/0x110
         entry_SYSCALL_64_after_hwframe+0x71/0x79
} hitcount:         83
{ common_stacktrace:
         virtqueue_add+0x215/0xde0
         virtqueue_add_outbuf+0x3a/0x60
         start_xmit+0x45d/0x7f0
         dev_hard_start_xmit+0xcd/0x260
         sch_direct_xmit+0xdf/0x260
         __dev_queue_xmit+0xc91/0x1100
         ip_finish_output2+0x481/0x4f0
         __ip_queue_xmit+0x664/0x6f0
         __tcp_transmit_skb+0x899/0xa70
         tcp_write_xmit+0x885/0x11a0
         __tcp_push_pending_frames+0x32/0xc0
         tcp_sendmsg_locked+0xdbe/0x1040
         tcp_sendmsg+0x2c/0x50
         __sock_sendmsg+0x6c/0xb0
         sock_write_iter+0x110/0x160
         vfs_write+0x2fc/0x350
} hitcount:        392

Totals:
    Hits: 524
    Entries: 22
    Dropped: 0


-- Steve