* Oleg Nesterov <o...@redhat.com> [2013-04-09 15:33:33]: > On 04/07, Srikar Dronamraju wrote: > > > > * Oleg Nesterov <o...@redhat.com> [2013-04-01 18:08:51]: > > > > > diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c > > > index e91a354..db2718a 100644 > > > --- a/kernel/trace/trace_uprobe.c > > > +++ b/kernel/trace/trace_uprobe.c > > > @@ -515,15 +515,26 @@ static void uprobe_trace_print(struct trace_uprobe > > > *tu, > > > int size, i; > > > struct ftrace_event_call *call = &tu->call; > > > > > > - size = SIZEOF_TRACE_ENTRY(1) + tu->size; > > > + if (is_ret_probe(tu)) > > > > One nit: > > Here and couple of places below .. we could check for func instead of > > is_ret_probe() right? > > Yes we could. And note that we do not really need both uprobe_trace_func() > and uretprobe_perf_func(), we could use a single function and check "func". > > But: > > > Or is there an advantage of checking is_ret_probe() over func? > > I believe yes. Firstly, we can't use 0ul as "invalid func address" to detect > the !is_ret_probe() case, we need, say, -1ul which probably needs a symbolic > name. In fact, I'd prefer to add another "is_return" argument if we want to > avoid is_ret_probe() and unify 2 functions. > > But more importantly, I think that is_ret_probe() is much more grep-friendly > and thus more understandable and consistent with other checks which can not > rely on "func".
Okay, Agree. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
