On Tue, Jul 14, 2026 at 10:10:04AM +0900, Masami Hiramatsu (Google) wrote:
> - char buf[MAX_ARGSTR_LEN + 1];
> + char buf[MAX_COMMON_HEAD_LEN + 1];
> ...
> +#define MAX_ARGSTR_LEN 255
> +#define MAX_COMMON_HEAD_LEN 63
Keeping the head buffer at 63 avoids growing it to 256, but it also
preserves a pre-existing truncation of the kprobe/fprobe head: both
trace_kprobe_match_command_head() and trace_fprobe_match_command_head()
snprintf() the symbol / function name into this buffer ("%s" or "%s+%u").
Kernel symbols can be far longer than 63 -- Rust-mangled names are
routinely 150-200+ chars (KSYM_NAME_LEN is 512); I see 199-char symbols
in /proc/kallsyms here.
This is the same delete-/match-by-command path you just fixed for the
args matcher in commit 15f197856d68 ("tracing/probes: Avoid temporary
buffer truncation in trace_probe_match_command_args()"):
dyn_event_release() passes the symbol as argv[0] to
*_match_command_head(), which then calls trace_probe_match_command_args().
The head runs first, so for a probe on a long symbol the head strcmp()
already fails and the probe cannot be matched/deleted by full command --
before the args fix is even reached.
Would it make sense to give the head matchers the same direct-comparison
treatment instead of a fixed buffer -- compare the symbol (and optional
"+offset") against argv[0] directly? uprobe already compares its filename
directly, so mainly kprobe and fprobe would need it, and
MAX_COMMON_HEAD_LEN could then be dropped.
Thanks,
Xusheng
