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 <[email protected]> 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. > 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/[email protected]?part=5
