From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Keun-O Park <kpark3469@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
keun-o.park@windriver.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tracepoints: prevents null probe from being added
Date: Wed, 20 Mar 2013 22:45:02 -0400 [thread overview]
Message-ID: <20130321024502.GB3874@Krystal> (raw)
In-Reply-To: <CA+KhAHaWT5FR5J8iBr_DExrNTBC50LyEo8NG-qZbF6NPEy+zFA@mail.gmail.com>
* Keun-O Park (kpark3469@gmail.com) wrote:
> On Thu, Mar 21, 2013 at 8:01 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Wed, 2013-03-20 at 14:01 -0400, Mathieu Desnoyers wrote:
> >> * Steven Rostedt (rostedt@goodmis.org) wrote:
> >> > On Wed, 2013-03-20 at 12:18 +0900, kpark3469@gmail.com wrote:
> >> > > From: Sahara <keun-o.park@windriver.com>
> >> > >
> >> > > Somehow tracepoint_entry_add/remove_probe functions allow a null probe
> >> > > function.
> >> >
> >> > You actually hit this in practice, or is this just something that you
> >> > observe from code review?
> >> >
> >> > > Especially on getting a null probe in remove function, it seems
> >> > > to be used to remove all probe functions in the entry.
> >> >
> >> > Hmm, that actually sounds like a feature.
> >>
> >> Yep. It's been a long time since I wrote this code, but the removal code
> >> seems to use NULL probe pointer to remove all probes for a given
> >> tracepoint.
> >>
> >> I'd be tempted to just validate non-NULL probe within
> >> tracepoint_entry_add_probe() and let other sites as is, just in case
> >> anyone would be using this feature.
> >>
> >> I cannot say that I have personally used this "remove all" feature much
> >> though.
> >>
> >
> > I agree. I don't see anything wrong in leaving the null probe feature in
> > the removal code. But updating the add code looks like a proper change.
> >
> > -- Steve
> >
> >
>
> Hello Steve & Mathieu,
> If we want to leave the null probe feature enabled, I think it would
> be better modifying the code like the following for code efficiency.
>
> @@ -112,7 +112,8 @@ tracepoint_entry_add_probe(struct tracepoint_entry *entry,
> int nr_probes = 0;
> struct tracepoint_func *old, *new;
>
> - WARN_ON(!probe);
> + if (WARN_ON(!probe))
> + return ERR_PTR(-EINVAL);
>
> debug_print_probes(entry);
> old = entry->funcs;
> @@ -152,14 +153,15 @@ tracepoint_entry_remove_probe(struct tracepoint_entry *ent
>
> debug_print_probes(entry);
> /* (N -> M), (N > 1, M >= 0) probes */
> - for (nr_probes = 0; old[nr_probes].func; nr_probes++) {
> - if (!probe ||
> - (old[nr_probes].func == probe &&
> - old[nr_probes].data == data))
> - nr_del++;
> + if (probe) {
> + for (nr_probes = 0; old[nr_probes].func; nr_probes++) {
> + if (old[nr_probes].func == probe &&
> + old[nr_probes].data == data)
> + nr_del++;
> + }
> }
>
> - if (nr_probes - nr_del == 0) {
> + if (!probe || nr_probes - nr_del == 0) {
We might want to do:
if (probe) {
...
} else {
nr_del = nr_probes;
}
if (nr_probes - nr_del == 0) {
...
}
rather than:
if (probe) {
...
}
if (!probe || nr_probes - nr_del == 0) {
...
}
Using nr_del makes the code easier to follow IMHO.
Thanks,
Mathieu
> /* N -> 0, (N > 1) */
> entry->funcs = NULL;
> entry->refcount = 0;
>
> Because we know handing over the null probe to
> tracepoint_entry_add_probe is not possible,
> we don't have to check if the probe is null or not within for loop. If
> the probe is null, it's just enough to add !probe in
> 'if(nr_probes-nr_del==0)'. And, with additional if-clause wrapping
> for-loop, falling through for-loop can be prevented when probe is
> null.
>
> @@ -173,8 +172,7 @@ tracepoint_entry_remove_probe(struct tracepoint_entry *entry
> if (new == NULL)
> return ERR_PTR(-ENOMEM);
> for (i = 0; old[i].func; i++)
> - if (probe &&
> - (old[i].func != probe || old[i].data != data))
> + if (old[i].func != probe || old[i].data != data)
> new[j++] = old[i];
> new[nr_probes - nr_del].func = NULL;
> entry->refcount = nr_probes - nr_del;
>
> We don't have to check the probe here too. We know probe is always true here.
> Thanks.
>
> -- Kpark
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2013-03-21 2:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 3:18 [PATCH] tracepoints: prevents null probe from being added kpark3469
2013-03-20 17:31 ` Steven Rostedt
2013-03-20 18:01 ` Mathieu Desnoyers
2013-03-20 23:01 ` Steven Rostedt
2013-03-21 1:39 ` Keun-O Park
2013-03-21 1:45 ` Keun-O Park
2013-03-21 2:45 ` Mathieu Desnoyers [this message]
2013-03-21 3:03 ` Keun-O Park
2013-03-21 3:33 ` Mathieu Desnoyers
2013-03-21 4:25 ` Keun-O Park
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=20130321024502.GB3874@Krystal \
--to=mathieu.desnoyers@efficios.com \
--cc=keun-o.park@windriver.com \
--cc=kpark3469@gmail.com \
--cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.