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

[Google]

On Fri, 24 Jul 2026 10:33:17 +0800
Zhan Xusheng <zhanxusheng1024@xxxxxxxxx> wrote:

> 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.

Hmm, good catch! OK, it seems trace_*probe_match_command_head() need
to be updated. Let me fix it!

> 
> 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.

Yeah, that is the best way to solve this issue.

Thanks for pointing it out!

> 
> Thanks,
> Xusheng


-- 
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>