From: John Stultz <jstultz@google.com>
To: LKML <linux-kernel@vger.kernel.org>
Cc: John Stultz <jstultz@google.com>,
Steven Rostedt <rostedt@goodmis.org>,
Alexander Potapenko <glider@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
kernel-team@android.com
Subject: [RFC][PATCH] lib: stacklog_debug: Introduce helper tool for collecting and displaying stacktraces
Date: Thu, 10 Oct 2024 14:28:05 -0700 [thread overview]
Message-ID: <20241010212813.2125851-1-jstultz@google.com> (raw)
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?
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: kernel-team@android.com
Signed-off-by: John Stultz <jstultz@google.com>
---
include/linux/stacklog_debug.h | 13 ++++
lib/Kconfig | 8 +++
lib/Makefile | 1 +
lib/stacklog_debug.c | 110 +++++++++++++++++++++++++++++++++
4 files changed, 132 insertions(+)
create mode 100644 include/linux/stacklog_debug.h
create mode 100644 lib/stacklog_debug.c
diff --git a/include/linux/stacklog_debug.h b/include/linux/stacklog_debug.h
new file mode 100644
index 000000000000..d88f05d7000a
--- /dev/null
+++ b/include/linux/stacklog_debug.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#ifndef _LINUX_STACKLOG_DEBUG_H
+#define _LINUX_STACKLOG_DEBUG_H
+
+#ifdef CONFIG_STACKLOG_DEBUG
+void stacklog_debug_save(void);
+#else
+static inline void stacklog_debug_save(void)
+{
+}
+#endif
+#endif
diff --git a/lib/Kconfig b/lib/Kconfig
index b38849af6f13..3a90b9d4f8de 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -725,6 +725,14 @@ config REF_TRACKER
depends on STACKTRACE_SUPPORT
select STACKDEPOT
+config STACKLOG_DEBUG
+ bool "Debug tool for logging and later displaying stacktraces"
+ select STACKDEPOT
+ select STACKDEPOT_ALWAYS_INIT
+ help
+ Enables debug infrastructure for logging unique stack traces at
+ a specific point, which can be later displayed from userland.
+
config SBITMAP
bool
diff --git a/lib/Makefile b/lib/Makefile
index 773adf88af41..5a07573be73c 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -264,6 +264,7 @@ obj-$(CONFIG_IRQ_POLL) += irq_poll.o
obj-$(CONFIG_POLYNOMIAL) += polynomial.o
+obj-$(CONFIG_STACKLOG_DEBUG) += stacklog_debug.o
# stackdepot.c should not be instrumented or call instrumented functions.
# Prevent the compiler from calling builtins like memcmp() or bcmp() from this
# file.
diff --git a/lib/stacklog_debug.c b/lib/stacklog_debug.c
new file mode 100644
index 000000000000..72ffbacee4b7
--- /dev/null
+++ b/lib/stacklog_debug.c
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ */
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/sched.h>
+#include <linux/vmalloc.h>
+#include <linux/stackdepot.h>
+#include <linux/debugfs.h>
+#include <linux/stacklog_debug.h>
+
+#define STACKDEPTH 32
+#define BUFSZ 4096
+
+#define LIST_ENTRIES 512
+DEFINE_SPINLOCK(stack_lock);
+depot_stack_handle_t stack_list[LIST_ENTRIES];
+int head, tail;
+
+void stacklog_debug_save(void)
+{
+ unsigned long entries[STACKDEPTH];
+ depot_stack_handle_t stack_hash;
+ unsigned long flags;
+ unsigned int n;
+ int i;
+
+ n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
+ stack_hash = stack_depot_save(entries, n, GFP_NOWAIT);
+ if (!stack_hash)
+ return;
+
+ spin_lock_irqsave(&stack_lock, flags);
+ for (i = head; i < tail; i++)
+ if (stack_list[i % LIST_ENTRIES] == stack_hash)
+ goto out;
+
+ stack_list[(tail++ % LIST_ENTRIES)] = stack_hash;
+
+ if (tail % LIST_ENTRIES == head % LIST_ENTRIES)
+ head++;
+
+ if (tail >= 2 * LIST_ENTRIES) {
+ head %= LIST_ENTRIES;
+ tail %= LIST_ENTRIES;
+ if (tail < head)
+ tail += LIST_ENTRIES;
+ }
+out:
+ spin_unlock_irqrestore(&stack_lock, flags);
+}
+
+#ifdef CONFIG_DEBUG_FS
+static int stacklog_stats_show(struct seq_file *s, void *unused)
+{
+ char *buf = kmalloc(BUFSZ, GFP_NOWAIT);
+ unsigned int nr_entries;
+ unsigned long flags;
+ int i, start, stop;
+
+ if (!buf)
+ return -ENOMEM;
+
+ spin_lock_irqsave(&stack_lock, flags);
+ start = head;
+ stop = tail;
+ spin_unlock_irqrestore(&stack_lock, flags);
+
+ if (start == stop)
+ goto out;
+
+ for (i = start; i < stop; i++) {
+ unsigned long *ent;
+ u32 hash;
+
+ /*
+ * We avoid holdings the lock over the entire loop
+ * just to be careful as we don't want to trip a
+ * call path that calls back into stacklog_debug_save
+ * which would deadlock, so hold the lock minimally
+ * (and be ok with the data changing between loop
+ * iterations).
+ */
+ spin_lock_irqsave(&stack_lock, flags);
+ hash = stack_list[i % LIST_ENTRIES];
+ spin_unlock_irqrestore(&stack_lock, flags);
+
+ nr_entries = stack_depot_fetch(hash, &ent);
+ stack_trace_snprint(buf, BUFSZ, ent, nr_entries, 0);
+ seq_printf(s, "[idx: %i hash: %ld]====================\n%s\n\n",
+ i - start, (long)hash, buf);
+ }
+out:
+ kfree(buf);
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(stacklog_stats);
+
+static int __init stacklog_debug_init(void)
+{
+ debugfs_create_file("stacklog_debug", 0400, NULL, NULL,
+ &stacklog_stats_fops);
+ return 0;
+}
+
+late_initcall(stacklog_debug_init);
+#endif
--
2.47.0.rc1.288.g06298d1525-goog
reply other threads:[~2024-10-10 21:28 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241010212813.2125851-1-jstultz@google.com \
--to=jstultz@google.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=glider@google.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox