Re: [PATCH v3 4/5] tracing/probes: Extend max length of argument string

[Zhan Xusheng <zhanxusheng1024@gmail.com>]

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