Re: [PATCH] samples/ftrace: reject zero ftrace-ops call count
From: Steven Rostedt <rostedt@goodmis.org>
Date: 2026-06-09 01:03:14
Also in:
lkml
On Tue, 9 Jun 2026 00:44:23 +0000 Samuel Moelius [off-list ref] wrote:
The ftrace-ops sample exposes nr_function_calls as a module parameter and uses it as the divisor when printing the measured time per call. Loading the module with nr_function_calls=0 skips the benchmark loop and then divides the elapsed time by zero, crashing the kernel during sample module initialization.
This change is rather pointless, but whatever.
quoted hunk ↗ jump to hunk
Reject a zero call count before registering any ftrace ops. Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius <redacted> --- samples/ftrace/ftrace-ops.c | 5 +++++ 1 file changed, 5 insertions(+)diff --git a/samples/ftrace/ftrace-ops.c b/samples/ftrace/ftrace-ops.c index 68d6685c80bd..d5adaa61484f 100644 --- a/samples/ftrace/ftrace-ops.c +++ b/samples/ftrace/ftrace-ops.c@@ -190,6 +190,11 @@ static int __init ftrace_ops_sample_init(void) tracer_irrelevant = ops_func_count; } + if (!nr_function_calls) { + pr_err("nr_function_calls must be non-zero\n"); + return -EINVAL;
No need to print that the admin did something stupid.
+ }
+
pr_info("registering:\n"
" relevant ops: %u\n"
" tracee: %ps\n"
In fact, I would just change the output to be:
pr_info("Attempted %u calls to %ps in %lluns (%lluns / call)\n",
nr_function_calls, tracee_relevant,
period, nr_function_calls ? div_u64(period, nr_function_calls) : -1LL);
and have garbage in, garbage out.
-- Steve