All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: kpark3469@gmail.com, 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 14:01:13 -0400	[thread overview]
Message-ID: <20130320180113.GA24537@Krystal> (raw)
In-Reply-To: <1363800712.6345.17.camel@gandalf.local.home>

* 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.

Thanks,

Mathieu

> 
> > But, the code is not handled as expected. Since the tracepoint_entry
> > maintains funcs array's last func as NULL in order to mark it as the end
> > of the array. Also NULL func is used in for-loop to check out the end of
> > the loop. So if there's NULL func in the entry's funcs, the for-loop
> > will be abruptly ended in the middle of operation.
> > Also checking out if probe is null in for-loop is not efficient.
> > 
> > Signed-off-by: Sahara <keun-o.park@windriver.com>
> > ---
> >  kernel/tracepoint.c |   18 ++++++++++++------
> >  1 files changed, 12 insertions(+), 6 deletions(-)
> > 
> > diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
> > index 0c05a45..30f427e 100644
> > --- a/kernel/tracepoint.c
> > +++ b/kernel/tracepoint.c
> > @@ -112,7 +112,10 @@ tracepoint_entry_add_probe(struct tracepoint_entry *entry,
> >  	int nr_probes = 0;
> >  	struct tracepoint_func *old, *new;
> >  
> > -	WARN_ON(!probe);
> > +	if (unlikely(!probe)) {
> > +		WARN_ON(!probe);
> > +		return ERR_PTR(-EINVAL);
> > +	}
> 
> Um, you want:
> 
> 	if (WARN_ON(!probe))
> 		return ERR_PTR(-EINVAL);
> 
> >  
> >  	debug_print_probes(entry);
> >  	old = entry->funcs;
> > @@ -147,15 +150,19 @@ tracepoint_entry_remove_probe(struct tracepoint_entry *entry,
> >  
> >  	old = entry->funcs;
> >  
> > +	if (unlikely(!probe)) {
> > +		WARN_ON(!probe);
> > +		return ERR_PTR(-EINVAL);
> > +	}
> 
> Here too if it wasn't intended to allow removal of all probes from a
> tracepoint.
> 
> > +
> >  	if (!old)
> >  		return ERR_PTR(-ENOENT);
> >  
> >  	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))
> > +		if (old[nr_probes].func == probe &&
> > +		     old[nr_probes].data == data)
> >  			nr_del++;
> >  	}
> >  
> > @@ -173,8 +180,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)
> 
> This makes it look like the null probe was intentional.
> 
> -- Steve
> 
> >  				new[j++] = old[i];
> >  		new[nr_probes - nr_del].func = NULL;
> >  		entry->refcount = nr_probes - nr_del;
> 
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2013-03-20 18:01 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 [this message]
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
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=20130320180113.GA24537@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.