Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755818AbbDUTEJ (ORCPT ); Tue, 21 Apr 2015 15:04:09 -0400 Received: from mga02.intel.com ([134.134.136.20]:33999 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754251AbbDUTEG (ORCPT ); Tue, 21 Apr 2015 15:04:06 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,617,1422950400"; d="scan'208";a="559612956" Message-ID: <1429643039.9234.4.camel@picadillo> Subject: Re: [PATCH v4 0/7] tracing: 'hist' triggers From: Tom Zanussi To: Daniel Wagner Cc: rostedt@goodmis.org, masami.hiramatsu.pt@hitachi.com, namhyung@kernel.org, andi@firstfloor.org, alexei.starovoitov@gmail.com, linux-kernel@vger.kernel.org Date: Tue, 21 Apr 2015 12:03:59 -0700 In-Reply-To: <55362849.7020000@monom.org> References: <5534F684.9050303@monom.org> <1429567429.2757.7.camel@picadillo> <55362849.7020000@monom.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5442 Lines: 159 On Tue, 2015-04-21 at 12:36 +0200, Daniel Wagner wrote: > Hi Tom, > > On 04/21/2015 12:03 AM, Tom Zanussi wrote: > > On Mon, 2015-04-20 at 14:52 +0200, Daniel Wagner wrote: > >> On 04/10/2015 06:05 PM, Tom Zanussi wrote: > >> So I am wondering if the path from ftrace_trigger_soft_disabled() > >> to event_triggers_call() is supposed never to happen? The comment > >> on ftrace_trigger_soft_disabled() indicate this might happen on > >> normal operation: > >> > > > > So I looked at this on the plane and you're right, this is a path that > > should never be taken in this case, since the hist trigger does set the > > post_trigger flag and should therefore TRIGGER_COND would be true and > > that block should never be entered. > > > > However, the code that registers the trigger first enables the event, > > then sets the cond flag, which would allow this to happen - a trigger > > expecting data would be passed a NULL rec. > > > > Can you try the patch below and see if it fixes the problem? (untested > > and I haven't even had a chance to compile-test it..) > > Thanks for the explanation. With that and your patch I could get > it working. There are a couple of calling places missing in your > patch. With them it works nicely. Maybe moving update_cond_flag() > inside trace_event_trigger_enable_disable() would be an option? > Yeah, I guess I missed the most important bit in my haste, but glad it works for you now. I'll write up a proper patch as soon as I can.. Thanks, Tom > cheers, > daniel > > > diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c > index 4d8f5df..221ab1f 100644 > --- a/kernel/trace/trace_events_hist.c > +++ b/kernel/trace/trace_events_hist.c > @@ -1471,11 +1471,12 @@ static int hist_register_trigger(char *glob, struct event_trigger_ops *ops, > list_add_rcu(&data->list, &file->triggers); > ret++; > > + update_cond_flag(file); > if (trace_event_trigger_enable_disable(file, 1) < 0) { > list_del_rcu(&data->list); > + update_cond_flag(file); > ret--; > } > - update_cond_flag(file); > out: > return ret; > } > diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c > index 8c8f2ee..e47a229 100644 > --- a/kernel/trace/trace_events_trigger.c > +++ b/kernel/trace/trace_events_trigger.c > @@ -1264,6 +1264,7 @@ int event_enable_trigger_func(struct event_command *cmd_ops, > goto out_free; > } > > + update_cond_flag(file); > ret = trace_event_enable_disable(event_enable_file, 1, 1); > if (ret < 0) > goto out_put; > @@ -1286,6 +1287,7 @@ int event_enable_trigger_func(struct event_command *cmd_ops, > out_disable: > trace_event_enable_disable(event_enable_file, 0, 1); > out_put: > + update_cond_flag(file); > module_put(event_enable_file->event_call->mod); > out_free: > if (cmd_ops->set_filter) > > > > > > Tom > > > > [PATCH] tracing: Update cond flag before enabling or disabling a trigger > > > > Before a trigger is enabled, the cond flag should be set beforehand, > > otherwise an trigger that's expecting to process a trace record > > (e.g. one with post_trigger set) could be invoked without one. > > > > Likewise a trigger's cond flag should be reset after it's disabled, > > not before. > > > > Signed-off-by: Tom Zanussi > > --- > > kernel/trace/trace_events_trigger.c | 10 ++++++---- > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c > > index 7105f15..108e46c 100644 > > --- a/kernel/trace/trace_events_trigger.c > > +++ b/kernel/trace/trace_events_trigger.c > > @@ -546,11 +546,12 @@ static int register_trigger(char *glob, struct event_trigger_ops *ops, > > list_add_rcu(&data->list, &file->triggers); > > ret++; > > > > + update_cond_flag(file); > > if (trace_event_trigger_enable_disable(file, 1) < 0) { > > list_del_rcu(&data->list); > > + update_cond_flag(file); > > ret--; > > } > > - update_cond_flag(file); > > out: > > return ret; > > } > > @@ -578,8 +579,8 @@ void unregister_trigger(char *glob, struct event_trigger_ops *ops, > > if (data->cmd_ops->trigger_type == test->cmd_ops->trigger_type) { > > unregistered = true; > > list_del_rcu(&data->list); > > - update_cond_flag(file); > > trace_event_trigger_enable_disable(file, 0); > > + update_cond_flag(file); > > break; > > } > > } > > @@ -1324,11 +1325,12 @@ int event_enable_register_trigger(char *glob, > > list_add_rcu(&data->list, &file->triggers); > > ret++; > > > > + update_cond_flag(file); > > if (trace_event_trigger_enable_disable(file, 1) < 0) { > > list_del_rcu(&data->list); > > + update_cond_flag(file); > > ret--; > > } > > - update_cond_flag(file); > > out: > > return ret; > > } > > @@ -1351,8 +1353,8 @@ void event_enable_unregister_trigger(char *glob, > > (enable_data->file == test_enable_data->file)) { > > unregistered = true; > > list_del_rcu(&data->list); > > - update_cond_flag(file); > > trace_event_trigger_enable_disable(file, 0); > > + update_cond_flag(file); > > break; > > } > > } > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/