From: Tom Zanussi <zanussi@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: axelrasmussen@google.com, mhiramat@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/5] tracing: Update synth command errors
Date: Tue, 08 Dec 2020 12:32:08 -0600 [thread overview]
Message-ID: <d44d45dfd9d540b7dae7d645ce05a3f7bb79c03c.camel@kernel.org> (raw)
In-Reply-To: <20201208125340.407150f2@gandalf.local.home>
Hi Steve,
On Tue, 2020-12-08 at 12:53 -0500, Steven Rostedt wrote:
> On Tue, 08 Dec 2020 11:34:41 -0600
> Tom Zanussi <zanussi@kernel.org> wrote:
>
> > Unfortunately, you're correct, if you have a script that creates a
> > synthetic event without semicolons, this patchset will break it, as
> > I
> > myself found out and fixed in patch 4 ([PATCH v3 4/5]
> > selftests/ftrace:
> > Add synthetic event field separators) [4].
> >
> > So whereas before this would work, even though it shouldn't have in
> > the
> > first place:
> >
> > # echo 'wakeup_latency u64 lat pid_t pid char comm[16]' >
> > synthetic_events
> >
> > it now has to be:
> >
> > # echo 'wakeup_latency u64 lat; pid_t pid; char comm[16]' >
> > synthetic_events
> >
> > So yeah, this patchset fixes a set of parsing bugs for things that
> > shouldn't have been accepted as valid, but shouldn't break things
> > that
> > are obviously valid.
> >
> > If it's too late to fix them, though, I guess we'll just have to
> > live
> > with them, or some other option?
>
>
> I would suggest allowing the old interface work (with no new
> features, for
> backward compatibility), but new things like "char comm[16]" we
> require
> semicolons.
>
> One method to do this is to add to the start of reading the string,
> and
> checking if it has semicolons. If it does not, we create a new string
> with
> them, but make sure that the string does not include new changes.
>
> strncpy_from_user(buffer, user_buff, sizeof(buffer));
>
> if (!strstr(buffer, ";")) {
> if (!audit_old_buffer(buffer))
> goto error;
> insert_colons(buffer);
> }
>
>
> That is, if the buffer does not have semicolons, then check if it is
> a
> valid "old format", and if not, we error out. Otherwise, we insert
> the
> colons into the buffer, and process that as if the user put in
> colons:
>
> That is:
>
> echo 'wakeup_latency u64 lat pid_t pid' > synthetic_events
>
> would change the buffer to:
>
> "wakeup_latency u64 lat; pid_t pid;"
>
> And then put it through the normal processing. I think its OK that if
> the
> user were to cat out the synthetic events, it would see the
> semicolons even
> if it did not add them. As I don't think that will break userspace.
>
> Does that make sense?
>
Yeah, that should work, I'll try adding that.
Thanks,
Tom
> -- Steve
next prev parent reply other threads:[~2020-12-08 18:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 15:06 [PATCH v3 0/5] tracing: More synthetic event error fixes Tom Zanussi
2020-10-26 15:06 ` [PATCH v3 1/5] tracing/dynevent: Delegate parsing to create function Tom Zanussi
2020-12-07 23:33 ` Steven Rostedt
2020-12-08 9:50 ` Masami Hiramatsu
2020-10-26 15:06 ` [PATCH v3 2/5] tracing: Rework synthetic event command parsing Tom Zanussi
2020-12-08 0:16 ` Steven Rostedt
2020-12-08 17:37 ` Tom Zanussi
2020-10-26 15:06 ` [PATCH v3 3/5] tracing: Update synth command errors Tom Zanussi
2020-12-08 1:13 ` Steven Rostedt
2020-12-08 17:34 ` Tom Zanussi
2020-12-08 17:53 ` Steven Rostedt
2020-12-08 18:32 ` Tom Zanussi [this message]
2020-12-09 13:51 ` Masami Hiramatsu
2020-12-09 14:42 ` Steven Rostedt
2020-10-26 15:06 ` [PATCH v3 4/5] selftests/ftrace: Add synthetic event field separators Tom Zanussi
2020-10-26 15:06 ` [PATCH v3 5/5] selftests/ftrace: Update synthetic event syntax errors Tom Zanussi
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=d44d45dfd9d540b7dae7d645ce05a3f7bb79c03c.camel@kernel.org \
--to=zanussi@kernel.org \
--cc=axelrasmussen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.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;
as well as URLs for NNTP newsgroup(s).