From: Frederic Weisbecker <fweisbec@gmail.com>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: Ingo Molnar <mingo@elte.hu>, Tom Zanussi <tzanussi@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/7] tracing/filters: allow user to specify a filter val to be string
Date: Sat, 11 Apr 2009 16:35:34 +0200 [thread overview]
Message-ID: <20090411143533.GA5977@nowhere> (raw)
In-Reply-To: <49E04C61.10209@cn.fujitsu.com>
Hi Li,
On Sat, Apr 11, 2009 at 03:53:05PM +0800, Li Zefan wrote:
> Suppose we would like to trace all tasks named '123', but this
> will fail:
> # echo 'parent_comm == 123' > events/sched/sched_process_fork/filter
> bash: echo: write error: Invalid argument
>
> With this patch, we allow it by:
> # echo 'parent_comm == \123' > events/sched/sched_process_fork/filter
> # cat events/sched/sched_process_fork/filter
> parent_comm == 123
Well, IMHO, it would be rather better to just echo 'parent_comm == 123'
and let it answer depending of which filter_pred_*() callback we have
for the concerned field.
The culprit is this part in filter_parse():
pred->val = simple_strtoull(val_str, &tmp, 10);
if (tmp == val_str) {
pred->str_val = kstrdup(val_str, GFP_KERNEL);
if (!pred->str_val)
return -ENOMEM;
}
The idea would be to not anymore base the check on simple_strtoull to
guess whether this is a number or a string, making it act subsequently
to this assumption, which is not the good assumption we must base our
parsing yet.
Instead, we could let filter_parse only do the job of extracting the tokens
and then fill the whole pred struct without yet bothering about the type
of the value.
Thereafter we may defer the real value type checking on filter_add_pred()
depending on the type of the concerned field:
if (is_string_field()) {
add it as a string value;
} else {
do the check with simple_strtoull
looks good? Then go to the number size switch....
...
}
You see?
I think it would be a saner basis of parsing.
Thanks,
Frederic.
>
> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
> ---
> kernel/trace/trace_events_filter.c | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
> index 49b3ef5..2bf4481 100644
> --- a/kernel/trace/trace_events_filter.c
> +++ b/kernel/trace/trace_events_filter.c
> @@ -351,12 +351,19 @@ oom:
> return -ENOMEM;
> }
>
> +/*
> + * The filter format can be
> + * - 0, which means remove all filter preds
> + * - [||/&&] <field> ==/!= [\]<val>
> + *
> + * Note: '\' prevent a string type value beginning with a digit to
> + * be treated as a number
> + */
> int filter_parse(char **pbuf, struct filter_pred *pred)
> {
> char *tmp, *tok, *val_str = NULL;
> int tok_n = 0;
>
> - /* field ==/!= number, or/and field ==/!= number, number */
> while ((tok = strsep(pbuf, " \n"))) {
> if (tok_n == 0) {
> if (!strcmp(tok, "0")) {
> @@ -421,6 +428,8 @@ int filter_parse(char **pbuf, struct filter_pred *pred)
>
> pred->val = simple_strtoull(val_str, &tmp, 0);
> if (tmp == val_str) {
> + if (*val_str == '\\')
> + val_str++;
> pred->str_val = kstrdup(val_str, GFP_KERNEL);
> if (!pred->str_val)
> return -ENOMEM;
> --
> 1.5.4.rc3
>
next prev parent reply other threads:[~2009-04-11 14:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-11 7:52 [PATCH 0/7] tracing: bug fixes for tracing/filters Li Zefan
2009-04-11 7:52 ` [PATCH 1/7] tracing/filters: NUL-terminate user input filter Li Zefan
2009-04-11 7:52 ` [PATCH 2/7] tracing/filters: fix NULL pointer dereference Li Zefan
2009-04-12 10:06 ` [tip:tracing/urgent] " Li Zefan
2009-04-11 7:52 ` [PATCH 3/7] tracing/filters: allow user input integer to be oct or hex Li Zefan
2009-04-12 10:06 ` [tip:tracing/urgent] " Li Zefan
2009-04-11 7:53 ` [PATCH 4/7] tracing/filters: allow user to specify a filter val to be string Li Zefan
2009-04-11 14:35 ` Frederic Weisbecker [this message]
2009-04-12 10:04 ` Ingo Molnar
2009-04-13 1:37 ` Li Zefan
2009-04-13 3:45 ` Ingo Molnar
2009-04-11 7:55 ` [PATCH 5/7] tracing/filters: disallow newline as delimeter Li Zefan
2009-04-11 7:55 ` [PATCH 6/7] tracing/filters: return proper error code when writing filter file Li Zefan
2009-04-12 10:07 ` [tip:tracing/urgent] " Li Zefan
2009-04-11 7:55 ` [PATCH 7/7] tracing/filters: make filter preds RCU safe Li Zefan
2009-04-11 9:30 ` [PATCH 0/7] tracing: bug fixes for tracing/filters Tom Zanussi
2009-04-11 10:08 ` Li Zefan
2009-04-11 14:48 ` Frederic Weisbecker
2009-04-11 17:36 ` Paul E. McKenney
2009-04-11 17:58 ` Tom Zanussi
2009-04-12 10:02 ` Ingo Molnar
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=20090411143533.GA5977@nowhere \
--to=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tzanussi@gmail.com \
/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