From: Beau Belgrave <beaub@linux.microsoft.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
dcook@linux.microsoft.com
Subject: Re: [PATCH v2 1/2] tracing/user_events: Fix non-spaced field matching
Date: Thu, 2 May 2024 15:58:53 -0700 [thread overview]
Message-ID: <20240502225853.GA412-beaub@linux.microsoft.com> (raw)
In-Reply-To: <20240502171634.7e2ac794@gandalf.local.home>
On Thu, May 02, 2024 at 05:16:34PM -0400, Steven Rostedt wrote:
> On Tue, 23 Apr 2024 16:23:37 +0000
> Beau Belgrave <beaub@linux.microsoft.com> wrote:
>
> > When the ABI was updated to prevent same name w/different args, it
> > missed an important corner case when fields don't end with a space.
> > Typically, space is used for fields to help separate them, like
> > "u8 field1; u8 field2". If no spaces are used, like
> > "u8 field1;u8 field2", then the parsing works for the first time.
> > However, the match check fails on a subsequent register, leading to
> > confusion.
> >
> > This is because the match check uses argv_split() and assumes that all
> > fields will be split upon the space. When spaces are used, we get back
> > { "u8", "field1;" }, without spaces we get back { "u8", "field1;u8" }.
> > This causes a mismatch, and the user program gets back -EADDRINUSE.
> >
> > Add a method to detect this case before calling argv_split(). If found
> > force a space after the field separator character ';'. This ensures all
> > cases work properly for matching.
> >
> > With this fix, the following are all treated as matching:
> > u8 field1;u8 field2
> > u8 field1; u8 field2
> > u8 field1;\tu8 field2
> > u8 field1;\nu8 field2
>
> I'm curious, what happens if you have: "u8 field1; u8 field2;" ?
>
You'll get an extra whitespace during the copy, assuming it was really:
"u8 field1;u8 field2"
If it had spaces, this code wouldn't run.
> Do you care? As you will then create "u8 field1; u8 field2; "
>
> but I'm guessing the extra whitespace at the end doesn't affect anything.
>
Right, you get an extra byte allocated, but the argv_split() with ignore
it. The compare will work correctly (I've verified this just now to
double check).
IE these all match:
"Test u8 a; u8 b; "
"Test u8 a; u8 b;"
"Test u8 a; u8 b"
>
> >
> > Fixes: ba470eebc2f6 ("tracing/user_events: Prevent same name but different args event")
> > Signed-off-by: Beau Belgrave <beaub@linux.microsoft.com>
> > ---
> > kernel/trace/trace_events_user.c | 76 +++++++++++++++++++++++++++++++-
> > 1 file changed, 75 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
> > index 70d428c394b6..82b191f33a28 100644
> > --- a/kernel/trace/trace_events_user.c
> > +++ b/kernel/trace/trace_events_user.c
> > @@ -1989,6 +1989,80 @@ static int user_event_set_tp_name(struct user_event *user)
> > return 0;
> > }
> >
> > +/*
> > + * Counts how many ';' without a trailing space are in the args.
> > + */
> > +static int count_semis_no_space(char *args)
> > +{
> > + int count = 0;
> > +
> > + while ((args = strchr(args, ';'))) {
> > + args++;
> > +
> > + if (!isspace(*args))
> > + count++;
>
> This will count that "..;"
>
> This is most likely not an issue, but since I didn't see this case
> anywhere, I figured I bring it up just to confirm that it's not an issue.
>
It's not an issue on the matching/logic. However, you do get an extra
byte alloc (which doesn't bother me in this edge case).
Thanks,
-Beau
> -- Steve
>
>
> > + }
> > +
> > + return count;
> > +}
> > +
> > +/*
> > + * Copies the arguments while ensuring all ';' have a trailing space.
> > + */
> > +static char *insert_space_after_semis(char *args, int count)
> > +{
> > + char *fixed, *pos;
> > + int len;
> > +
> > + len = strlen(args) + count;
> > + fixed = kmalloc(len + 1, GFP_KERNEL);
> > +
> > + if (!fixed)
> > + return NULL;
> > +
> > + pos = fixed;
> > +
> > + /* Insert a space after ';' if there is no trailing space. */
> > + while (*args) {
> > + *pos = *args++;
> > +
> > + if (*pos++ == ';' && !isspace(*args))
> > + *pos++ = ' ';
> > + }
> > +
> > + *pos = '\0';
> > +
> > + return fixed;
> > +}
> > +
next prev parent reply other threads:[~2024-05-02 22:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-23 16:23 [PATCH v2 0/2] tracing/user_events: Fix non-spaced field matching Beau Belgrave
2024-04-23 16:23 ` [PATCH v2 1/2] " Beau Belgrave
2024-05-02 21:16 ` Steven Rostedt
2024-05-02 22:58 ` Beau Belgrave [this message]
2024-05-02 23:11 ` Steven Rostedt
2024-04-23 16:23 ` [PATCH v2 2/2] selftests/user_events: Add non-spacing separator check Beau Belgrave
2024-05-28 2:08 ` Masami Hiramatsu
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=20240502225853.GA412-beaub@linux.microsoft.com \
--to=beaub@linux.microsoft.com \
--cc=dcook@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--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).