Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751901AbdFZTKL (ORCPT ); Mon, 26 Jun 2017 15:10:11 -0400 Received: from mail-oi0-f47.google.com ([209.85.218.47]:33702 "EHLO mail-oi0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751461AbdFZTKF (ORCPT ); Mon, 26 Jun 2017 15:10:05 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170626053844.5746-1-joelaf@google.com> <20170626053844.5746-2-joelaf@google.com> <20170626125226.05c9a80e@gandalf.local.home> From: Joel Fernandes Date: Mon, 26 Jun 2017 12:10:04 -0700 Message-ID: Subject: Re: [PATCH v4 1/3] tracing: Add support for recording tgid of tasks To: Steven Rostedt Cc: LKML , Michael Sartain , kernel-team@android.com, Ingo Molnar Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1709 Lines: 49 On Mon, Jun 26, 2017 at 12:02 PM, Joel Fernandes wrote: > On Mon, Jun 26, 2017 at 9:52 AM, Steven Rostedt wrote: >> On Sun, 25 Jun 2017 22:38:42 -0700 [..] >> >>> +{ >>> + struct trace_event_file *file; >>> + struct trace_array *tr; >>> + >>> + mutex_lock(&event_mutex); >>> + do_for_each_event_file(tr, file) { >>> + if (!(file->flags & EVENT_FILE_FL_ENABLED)) >>> + continue; >>> + >>> + if (enable) { >>> + tracing_start_tgid_record(); >> >> If we fail to start, the bit should not be set, and we should return >> failure. Note, it can only fail on the first try, as once it is >> allocated, you don't need to worry about it failing. Thus, if it fails, >> break out of the loop now and return failure. >> > > That seems Ok with me to do, I think a valid point. > > I think that I should do it in the second call to > tracing_start_tgid_record too then (__ftrace_event_enable_disable) to > error out if the allocation fails. > > While going this code I again, I noticed another potential issue in > __ftrace_event_enable_disable Sorry I hit send too soon! I was saying, While going through this code again I noticed another potential issue in __ftrace_event_enable_disable in existing code: Here we do: ret = call->class->reg(call, TRACE_REG_REGISTER, file); But in the error handling path we only do a tracing_stop_cmdline_record() and not clear the EVENT_FILE_FL_RECORDED_CMD_BIT flag. Is that not an issue? I am guessing because enabling of the event itself will fail, that's Ok. But just to keep it consistent, I am thinking if we should just clear the bit here. Thanks, Joel