From: "Raphaël Beamonte" <raphael.beamonte@gmail.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: "Raphaël Beamonte" <raphael.beamonte@gmail.com>,
"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
"Ingo Molnar" <mingo@redhat.com>, "Jiri Olsa" <jolsa@kernel.org>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Yunlong Song" <yunlong.song@huawei.com>,
"Matt Fleming" <matt.fleming@intel.com>,
"Kan Liang" <kan.liang@intel.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Namhyung Kim" <namhyung@kernel.org>,
"Hemant Kumar" <hemant@linux.vnet.ibm.com>,
"Masami Hiramatsu" <masami.hiramatsu.pt@hitachi.com>,
"Wang Nan" <wangnan0@huawei.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH] perf: fix confusing messages when not able to read trace events files
Date: Sun, 16 Aug 2015 21:39:12 -0400 [thread overview]
Message-ID: <d580114523f838994fb6a03a07327d557138e4e1.1439775095.git.raphael.beamonte@gmail.com> (raw)
In-Reply-To: <cover.1439775095.git.raphael.beamonte@gmail.com>
In-Reply-To: <cover.1439775095.git.raphael.beamonte@gmail.com>
If a non-root user tries to specify a trace event and the tracefs
files can't be read, it will tell about it in a somewhat cryptic
way and as well say that the tracepoint is unknown, which is
obvious, since the tracefs files were not read.
This patch changes this behavior by using the debugfs__strerror_open
function to report the access error in a more elegant way, as well as
provide a hint like the one provided by the perf trace tool.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100781
Signed-off-by: Raphaël Beamonte <raphael.beamonte@gmail.com>
---
tools/perf/util/parse-events.c | 14 +++++++++++---
tools/perf/util/parse-options.c | 6 ++++++
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 09f8d23..17f787c 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -398,6 +398,7 @@ static int add_tracepoint_multi_event(struct list_head *list, int *idx,
char *sys_name, char *evt_name)
{
char evt_path[MAXPATHLEN];
+ char errbuf[BUFSIZ];
struct dirent *evt_ent;
DIR *evt_dir;
int ret = 0;
@@ -405,7 +406,10 @@ static int add_tracepoint_multi_event(struct list_head *list, int *idx,
snprintf(evt_path, MAXPATHLEN, "%s/%s", tracing_events_path, sys_name);
evt_dir = opendir(evt_path);
if (!evt_dir) {
- perror("Can't open event dir");
+ debugfs__strerror_open(
+ errno, errbuf, sizeof(errbuf),
+ evt_path + strlen(debugfs_mountpoint) + 1);
+ fprintf(stderr, "%s\n", errbuf);
return -1;
}
@@ -437,13 +441,17 @@ static int add_tracepoint_event(struct list_head *list, int *idx,
static int add_tracepoint_multi_sys(struct list_head *list, int *idx,
char *sys_name, char *evt_name)
{
+ char errbuf[BUFSIZ];
struct dirent *events_ent;
DIR *events_dir;
int ret = 0;
events_dir = opendir(tracing_events_path);
if (!events_dir) {
- perror("Can't open event dir");
+ debugfs__strerror_open(
+ errno, errbuf, sizeof(errbuf),
+ tracing_events_path + strlen(debugfs_mountpoint) + 1);
+ fprintf(stderr, "%s\n", errbuf);
return -1;
}
@@ -1156,7 +1164,7 @@ int parse_events_option(const struct option *opt, const char *str,
struct parse_events_error err = { .idx = 0, };
int ret = parse_events(evlist, str, &err);
- if (ret)
+ if (ret && errno != EACCES)
parse_events_print_error(&err, str);
return ret;
diff --git a/tools/perf/util/parse-options.c b/tools/perf/util/parse-options.c
index 01626be..55319d9 100644
--- a/tools/perf/util/parse-options.c
+++ b/tools/perf/util/parse-options.c
@@ -400,6 +400,12 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,
return usage_with_options_internal(usagestr, options, 0);
switch (parse_short_opt(ctx, options)) {
case -1:
+ /* If the error is an access error, we should already have
+ * taken care of it, and the usage information will provide
+ * no help to the user.
+ */
+ if (errno == EACCES)
+ return -1;
return parse_options_usage(usagestr, options, arg, 1);
case -2:
goto unknown;
--
2.1.4
next prev parent reply other threads:[~2015-08-17 1:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-17 1:39 [PATCH] perf: bugzilla 100781 Raphaël Beamonte
2015-08-17 1:39 ` Raphaël Beamonte [this message]
2015-08-18 11:43 ` [PATCH] perf: fix confusing messages when not able to read trace events files Matt Fleming
2015-08-18 17:45 ` Raphaël Beamonte
2015-08-20 13:52 ` Matt Fleming
2015-08-24 20:51 ` Jiri Olsa
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=d580114523f838994fb6a03a07327d557138e4e1.1439775095.git.raphael.beamonte@gmail.com \
--to=raphael.beamonte@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=hemant@linux.vnet.ibm.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=matt.fleming@intel.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=rostedt@goodmis.org \
--cc=wangnan0@huawei.com \
--cc=yunlong.song@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®