Received: by 10.192.165.156 with SMTP id m28csp1502135imm; Fri, 13 Apr 2018 23:33:15 -0700 (PDT) X-Google-Smtp-Source: AIpwx48g+ifs2i01zJqE1Oeci4VaLcLxL0AuaouhizPbjIa99dNeYQVZ5uaiAui5YiixyF51GlsR X-Received: by 10.98.165.8 with SMTP id v8mr14152998pfm.225.1523687595275; Fri, 13 Apr 2018 23:33:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523687595; cv=none; d=google.com; s=arc-20160816; b=dW2ykt6YU57F0Z/WN6/1itf2RAQR+NqIGSoTjxuZIgLDUzapTqdNwIhjsEREGMrFtw DGl+pRTvkgyTxalsdKKuKYtyzgdQuavNe3da6hNoKNFrUPPuiTpjRP+7aIJf/0fzoJvc 1kmePSguo0oqm91dhnE/4/VwqUZykrA1FLEGx/1lbKb03CynzhrEkM/MRq2frr9S4yMh v8YZEH47aogk3FqkeIcbTX41XV6yUZPMTGQQxzsXTqJEBoAd8WkgXAbmn67acmmkar4U 6g6SOWwrn55o9BBVkmfXwmwL8LWGVykd2vc2VptyQwDZGOAcGT/GDIFqDko4hxXbzc4f 5Prw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dmarc-filter:arc-authentication-results; bh=qD3PIMEXGKWDc21rEeEH35f8GUr7SASO0Ab18ArY7GU=; b=Cueigk0wvX4TRQDY2JcuhyjKbIZyVkwfgyeEU3EuD5QWY0bHi1W/tWK1DC9y9e5VpK EqNskWTLKBIHQMfYXVWi4ai65nIrGJsKkIWoJAt0Rce+JsKAMjeuQx5x/JHoSMDYDlyL S6E4koiO6knubxsA8cZo46BEIa5nrUcwq8UKErEUPNcEnxfsMiK4U4hykGRVNxCx6cnQ 4QSnypfsXOv2IPzfTPbu+jOIRBauuGSEkrhDV5NwBOCET0i56zxYcegPojw33xAd3Q9X wPRT2RBPzTgnRp02qFSaebaDuWab8l2+i5KhlW8nZrCNXdnYDR+zRJWqao98qBlWToXN ajvQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 198si5381616pgg.546.2018.04.13.23.33.01; Fri, 13 Apr 2018 23:33:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751143AbeDNGbL (ORCPT + 99 others); Sat, 14 Apr 2018 02:31:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:56978 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750917AbeDNGbJ (ORCPT ); Sat, 14 Apr 2018 02:31:09 -0400 Received: from devbox (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EDA7A21779; Sat, 14 Apr 2018 06:31:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EDA7A21779 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=mhiramat@kernel.org Date: Sat, 14 Apr 2018 15:31:03 +0900 From: Masami Hiramatsu To: Tom Zanussi Cc: Steven Rostedt , tglx@linutronix.de, mhiramat@kernel.org, namhyung@kernel.org, vedang.patel@intel.com, bigeasy@linutronix.de, joel.opensrc@gmail.com, joelaf@google.com, mathieu.desnoyers@efficios.com, baohong.liu@intel.com, rajvi.jingar@intel.com, julia@ni.com, fengguang.wu@intel.com, linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org Subject: Re: [PATCH 2/6] tracing: Add trace event error log Message-Id: <20180414153103.f6cbea046ba951566015e58b@kernel.org> In-Reply-To: <1523577133.11817.31.camel@tzanussi-mobl.amr.corp.intel.com> References: <194bd34e689dd6df9e48855111fd6c5c66e37fc9.1523545519.git.tom.zanussi@linux.intel.com> <20180412182001.75bfb4e2@gandalf.local.home> <1523577133.11817.31.camel@tzanussi-mobl.amr.corp.intel.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 12 Apr 2018 18:52:13 -0500 Tom Zanussi wrote: > Hi Steve, > > On Thu, 2018-04-12 at 18:20 -0400, Steven Rostedt wrote: > > On Thu, 12 Apr 2018 10:13:17 -0500 > > Tom Zanussi wrote: > > > > > diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h > > > index 6fb46a0..f2dc7e6 100644 > > > --- a/kernel/trace/trace.h > > > +++ b/kernel/trace/trace.h > > > @@ -1765,6 +1765,9 @@ extern ssize_t trace_parse_run_command(struct file *file, > > > const char __user *buffer, size_t count, loff_t *ppos, > > > int (*createfn)(int, char**)); > > > > > > +extern void event_log_err(const char *loc, const char *cmd, const char *fmt, > > > + ...); > > > + > > > /* > > > * Normal trace_printk() and friends allocates special buffers > > > * to do the manipulation, as well as saves the print formats > > > diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c > > > index 05c7172..fd02e22 100644 > > > --- a/kernel/trace/trace_events.c > > > +++ b/kernel/trace/trace_events.c > > > @@ -1668,6 +1668,164 @@ static void ignore_task_cpu(void *data) > > > return ret; > > > } > > > > > > +#define EVENT_LOG_ERRS_MAX (PAGE_SIZE / sizeof(struct event_log_err)) > > > > > +#define EVENT_ERR_LOG_MASK (EVENT_LOG_ERRS_MAX - 1) > > > > BTW, the above only works if EVENT_LOG_ERRS_MAX is a power of two, > > which it's not guaranteed to be. > > > > My assumption was that we'd only ever need a page or two for the > error_log and so would always would be a power of two, since the size of > the struct event_log_err is 512. > > Anyway, I should probably have put comments about all this in the code, > and I will, but the way it works kind of assumes a very small number of > errors - it's replacing a simple 'last error' facility for the hist > triggers and making it a common facility for other things that have > similar needs like Masami's kprobe_events errors. For those purposes, I > assumed it would suffice to simply be able to show that last 8 or some > similar small number of errors and constantly recycle the slots. Correct. I don't think the error log entry size over 16, it is too much errors occur. User must check it before that. Or, we should push it printk buffer. > > Basically it just splits the page into 16 strings, 2 per error, one for > the actual error text, the other for the command the user entered. The > struct event_log_err just overlays a struct on top of 2 strings just to > make it easier to manage. > > Anyway, because it is such a small number, and we start with a zeroed > page, whenever we print the error log, we print all 16 strings even if > we only have one error (2 strings). The rest are NULL and print > nothing. We start with the tail, which could also be thought of as the > 'oldest' or the 'first' error in the buffer and just cycle through them > all. Hope that clears up some of the other questions you had about how > a non-full log gets printed, etc... > > > > + > > > +struct event_log_err { > > > + char err[MAX_FILTER_STR_VAL]; > > > + char cmd[MAX_FILTER_STR_VAL]; > > > +}; > > > > I like the event_log_err idea, but the above can be shrunk to: > > > > struct err_info { > > u8 type; /* I can only imagine 254 types */ > > u8 pos; /* MAX_FILTER_STR_VAR = 256 */ > > }; > > > > struct event_log_err { > > struct err_info info; > > char cmd[MAX_FILTER_STR_VAL]; > > }; > > > > There's no reason to put in a bunch of text that's going to be static > > anyway. Have a lookup table like we do for filters. > > > > + log_err("Variable name not unique, need to use fully qualified name (%s) for variable: ", fqvar(system, event_name, var_name, true)); > > > > Hmm, most of the log_errs use printf strings that get expanded, so need > a destination buffer, the event_log_err->err string, but I think I see > what you're getting at - that we can get rid of the format strings > altogether and make them static strings if we use the method of simply > printing the static string and putting a caret where the error is as > below. > > > > > Instead of making the fqvar, find the location of the variable, and add: > > > > blah blah $var blah blah > > ^ > > Variable name not unique, need to use fully qualified name for variable > > > > OK, if we can do this for every error type, then we can use the lookup > table and the caret position instead of format strings. Which means > getting rid of the simple ring of strings, but whatever.. From the viewpoint of kprobe events, I'm OK for either way. I'll rewrite parser to get parsing position correctly. Thanks! -- Masami Hiramatsu