From: Steven Rostedt <rostedt@goodmis.org>
To: Douglas Raillard <douglas.raillard@arm.com>
Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH] tracing: Fix synth event printk format for str fields
Date: Mon, 24 Mar 2025 09:40:05 -0400 [thread overview]
Message-ID: <20250324094005.045cd547@gandalf.local.home> (raw)
In-Reply-To: <a5af352b-9f0d-4280-8d7b-e72597e6265d@arm.com>
On Mon, 24 Mar 2025 10:18:50 +0000
Douglas Raillard <douglas.raillard@arm.com> wrote:
> > https://lore.kernel.org/all/b6bdb34e70d970e8026daa3503db6b8e5cdad524.1601848695.git.zanussi@kernel.org/T/#u
> >
> > So, I think it should always print the STR_VAR_LEN_MAX value.
>
> That makes sense. It's tempting to keep the actual length value though as native Rust strings are not null-terminated, so
> it could make it nicer to emit events from Rust code. From a cursory look, the in-tree Rust code seems to be using both
> &str and &CStr (the latter being null-terminated for FFI needs) so I'm not sure what's the plan around those
> and what's the established convention if any.
>
> > Steve, can you check it?
So I did take this patch, but thinking about this more, I may remove it.
The __get_str() doesn't expect a string end. The parser should limit it, as
the length of the string is saved in the ring buffer. Just like other trace
events where dynamically size strings only use "%s" and __get_str().
I think the real fix is to replace the "%.*s" with "%s".
-- Steve
next prev parent reply other threads:[~2025-03-24 13:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 18:09 [PATCH] tracing: Fix synth event printk format for str fields Douglas RAILLARD
2025-03-19 12:18 ` Masami Hiramatsu
2025-03-19 14:34 ` Douglas Raillard
2025-03-24 5:45 ` Masami Hiramatsu
2025-03-24 10:18 ` Douglas Raillard
2025-03-24 13:40 ` Steven Rostedt [this message]
2025-03-24 21:12 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250324094005.045cd547@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=douglas.raillard@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox