Re: [RFC PATCH v7 05/10] trace: make the stackmap capacity settable on the kernel command line
From: sashiko-bot@kernel.org
Date: 2026-09-12 08:58:41
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Booting with the parameter `ftrace_stackmap.bits` without providing a value causes a NULL pointer dereference, crashing the kernel during early boot. -- commit 7bbdd67c3f0e40d0b1656f5e92da61a336e639f5 Author: Pengfei Li [off-list ref] trace: make the stackmap capacity settable on the kernel command line This commit adds the ftrace_stackmap.bits kernel command line parameter to allow sizing the stackmap capacity at boot. The value is clamped between 10 and 18 to bound the worst-case element pool allocations.
quoted hunk ↗ jump to hunk
diff --git a/kernel/trace/trace_stackmap.c b/kernel/trace/trace_stackmap.c index 439d3be9e3516..49ea403822ba3 100644 --- a/kernel/trace/trace_stackmap.c +++ b/kernel/trace/trace_stackmap.c
[ ... ]
+static int __init stackmap_bits_setup(char *str)
+{
+ unsigned long val;
+
+ if (kstrtoul(str, 0, &val))[Severity: High] What happens if the ftrace_stackmap.bits boot parameter is passed without an equals sign and value? During early boot, parse_args() uses next_arg() to parse the command line. If the parameter is passed without a value (e.g., just ftrace_stackmap.bits), next_arg() assigns a NULL pointer to the value string. Does passing this NULL pointer directly to kstrtoul() cause an immediate NULL pointer dereference and kernel panic, since kstrtoul() does not check for a NULL pointer before dereferencing it?
+ return -EINVAL;
+ val = clamp_val(val, FTRACE_STACKMAP_BITS_MIN, FTRACE_STACKMAP_BITS_MAX);
+ stackmap_map_bits = val;
+ return 0;
+}
+early_param("ftrace_stackmap.bits", stackmap_bits_setup);-- Sashiko AI review · https://sashiko.dev/#/patchset/20260912083753.3426176-1-lipengfei28@xiaomi.com?part=5