From: Fangzheng Zhang <fangzheng.zhang@unisoc.com>
To: Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
Greg KH <gregkh@linuxfoundation.org>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<tkjos@google.com>, Fangzheng Zhang <fangzheng.zhang@unisoc.com>,
Fangzheng Zhang <fangzheng.zhang1003@gmail.com>,
Yuming Han <yuming.han@unisoc.com>
Subject: [PATCH 1/2] mm/slub: Add panic function when slub leaks
Date: Wed, 25 Sep 2024 11:22:55 +0800 [thread overview]
Message-ID: <20240925032256.1782-2-fangzheng.zhang@unisoc.com> (raw)
In-Reply-To: <20240925032256.1782-1-fangzheng.zhang@unisoc.com>
Perform real-time memory usage monitoring on the slub page
allocation paths, ie, kmalloc_large_alloced and alloc_slab_page.
When the usage exceeds the set threshole value, the panic function
will be triggered.
Signed-off-by: Fangzheng Zhang <fangzheng.zhang@unisoc.com>
---
mm/Kconfig | 11 ++++++++
mm/slub.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 87 insertions(+)
diff --git a/mm/Kconfig b/mm/Kconfig
index 09aebca1cae3..60cf72d4f0da 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -255,6 +255,17 @@ config SLUB_TINY
If unsure, say N.
+config SLUB_LEAK_PANIC
+ bool "Trigger panic when slub leaks"
+ default y
+ help
+ Detect slub leaks by monitoring its usage in real time on the page
+ allocation path of the slub. When the slub occupancy exceeds the
+ user-set value, it is considered that the slub is leaking at this
+ time, and a panic operation will be triggered immediately. Uers
+ can enable and set leak threshold by using the kernel command line
+ parameters "slub.leak_panic" and "slub.leak_panic_threshold".
+
config SLAB_MERGE_DEFAULT
bool "Allow slab caches to be merged"
default y
diff --git a/mm/slub.c b/mm/slub.c
index 21f71cb6cc06..91049f87ab98 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -42,6 +42,9 @@
#include <kunit/test.h>
#include <kunit/test-bug.h>
#include <linux/sort.h>
+#ifdef CONFIG_SLUB_LEAK_PANIC
+#include <linux/vmstat.h>
+#endif
#include <linux/debugfs.h>
#include <trace/events/kmem.h>
@@ -218,6 +221,15 @@ DEFINE_STATIC_KEY_FALSE(slub_debug_enabled);
#endif
#endif /* CONFIG_SLUB_DEBUG */
+/* Internal slub_leak_panic definitions */
+#ifdef CONFIG_SLUB_LEAK_PANIC
+#define K(x) ((x) << (PAGE_SHIFT-10))
+static bool __read_mostly slub_leak_panic_enabled;
+static unsigned int __read_mostly slub_leak_panic_threshold;
+static long max_slab_count, temp_slab_count;
+#endif
+
+
/* Structure holding parameters for get_partial() call chain */
struct partial_context {
gfp_t flags;
@@ -2424,6 +2436,21 @@ static inline struct slab *alloc_slab_page(gfp_t flags, int node,
if (folio_is_pfmemalloc(folio))
slab_set_pfmemalloc(slab);
+#ifdef CONFIG_SLUB_LEAK_PANIC
+ if (likely(slub_leak_panic_enabled) && slub_leak_panic_threshold > 0) {
+ max_slab_count = K(totalram_pages()) * slub_leak_panic_threshold / 100;
+ temp_slab_count = K(global_node_page_state_pages(NR_SLAB_RECLAIMABLE_B))
+ + K(global_node_page_state_pages(NR_SLAB_UNRECLAIMABLE_B))
+ + K(1 << order);
+ if (temp_slab_count > max_slab_count)
+ panic("SLAB LEAK: %s(temp_count %6luKB > max_count %6luKB):\n"
+ "%s gfp_mask=%#x(%pGg), order=%d kB, oom_score_adj=%d\n",
+ __func__, temp_slab_count, max_slab_count,
+ current->comm, flags, &flags, order,
+ current->signal->oom_score_adj);
+ }
+#endif
+
return slab;
}
@@ -4212,6 +4239,19 @@ static void *___kmalloc_large_node(size_t size, gfp_t flags, int node)
ptr = folio_address(folio);
lruvec_stat_mod_folio(folio, NR_SLAB_UNRECLAIMABLE_B,
PAGE_SIZE << order);
+#ifdef CONFIG_SLUB_LEAK_PANIC
+ if (likely(slub_leak_panic_enabled) && slub_leak_panic_threshold > 0) {
+ max_slab_count = K(totalram_pages()) * slub_leak_panic_threshold / 100;
+ temp_slab_count = K(global_node_page_state_pages(NR_SLAB_RECLAIMABLE_B))
+ + K(global_node_page_state_pages(NR_SLAB_UNRECLAIMABLE_B));
+ if (temp_slab_count > max_slab_count)
+ panic("SLAB LEAK: %s(temp_count %6luKB > max_count %6luKB):\n"
+ "%s gfp_mask=%#x(%pGg), order=%d kB, oom_score_adj=%d\n",
+ __func__, temp_slab_count, max_slab_count,
+ current->comm, flags, &flags, order,
+ current->signal->oom_score_adj);
+ }
+#endif
}
ptr = kasan_kmalloc_large(ptr, size, flags);
@@ -7443,3 +7483,39 @@ void get_slabinfo(struct kmem_cache *s, struct slabinfo *sinfo)
sinfo->cache_order = oo_order(s->oo);
}
#endif /* CONFIG_SLUB_DEBUG */
+
+/*
+ * The /sys/module/slub ABI
+ */
+#ifdef CONFIG_SLUB_LEAK_PANIC
+/*
+ * What: /sys/module/slub/parameters/leak_panic
+ * /sys/module/slub/parameters/leak_panic_threshold
+ * Date: Sep 2024
+ * KernelVersion: v6.6+
+ * Description: Used for slub memory leak check. When the user
+ * successfully allocates the slub page, it also performs
+ * statistics on the total slub usage in the system.
+ * When the usage exceeds the set value
+ * (threshold * memtotal / 100), it is considered that
+ * there is a risk of slub leakage in the system at this time.
+ * A panic operation will be triggered.
+ * Users: userspace
+ */
+MODULE_PARM_DESC(leak_panic, "Disable/Enable slub_leak_panic");
+module_param_named(leak_panic, slub_leak_panic_enabled, bool, 0644);
+
+static int slub_leak_panic_threshold_set(const char *val, const struct kernel_param *kp)
+{
+ return param_set_uint_minmax(val, kp, 0, 100);
+}
+
+static const struct kernel_param_ops slub_leak_panic_threshold_ops = {
+ .set = slub_leak_panic_threshold_set,
+ .get = param_get_uint,
+};
+
+MODULE_PARM_DESC(leak_panic_threshold,
+ "Upper limit value of slub, expressed as a percentage of memtotal (0 ~ 100)");
+module_param_cb(leak_panic_threshold,
+ &slub_leak_panic_threshold_ops, &slub_leak_panic_threshold, 0644);
+#endif /* CONFIG_SLUB_LEAK_PANIC */
--
2.17.1
next prev parent reply other threads:[~2024-09-25 3:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-25 3:22 [PATCH 0/2] Introduce " Fangzheng Zhang
2024-09-25 3:22 ` Fangzheng Zhang [this message]
2024-09-25 8:10 ` [PATCH 1/2] mm/slub: Add " Greg KH
2024-09-25 12:45 ` zhang fangzheng
2024-09-25 8:10 ` Greg KH
2024-09-25 11:39 ` kernel test robot
2024-09-25 12:10 ` kernel test robot
2024-09-25 3:22 ` [PATCH 2/2] Documentation: admin-guide: kernel-parameters: Add parameter description for slub_leak_panic function Fangzheng Zhang
2024-09-25 13:18 ` [PATCH 0/2] Introduce panic function when slub leaks Hyeonggon Yoo
2024-09-26 12:30 ` Vlastimil Babka
2024-09-27 7:28 ` zhang fangzheng
2024-09-27 8:01 ` Hyeonggon Yoo
2024-10-09 1:25 ` 答复: " 韩玉明 (Yuming Han)
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=20240925032256.1782-2-fangzheng.zhang@unisoc.com \
--to=fangzheng.zhang@unisoc.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=fangzheng.zhang1003@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=tkjos@google.com \
--cc=vbabka@suse.cz \
--cc=yuming.han@unisoc.com \
/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