From: Ingo Molnar <mingo@kernel.org>
To: Andi Kleen <ak@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Stephane Eranian <eranian@google.com>,
LKML <linux-kernel@vger.kernel.org>,
"mingo@elte.hu" <mingo@elte.hu>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Jiri Olsa <jolsa@redhat.com>
Subject: Re: [PATCH 2/2] perf: SNB exclusive PMU access for INST_RETIRED:PREC_DIST
Date: Sun, 21 Oct 2012 18:55:23 +0200 [thread overview]
Message-ID: <20121021165523.GA29247@gmail.com> (raw)
In-Reply-To: <20121019172018.GA2095@tassilo.jf.intel.com>
* Andi Kleen <ak@linux.intel.com> wrote:
> > > > This isn't limited to admin, right? So the above turns into a DoS on the
> > > > console.
> > > >
> > > Ok, so how about a WARN_ON_ONCE() instead?
> >
> > That should be fine I guess ;-)
>
> imho there is need for a generic mechanism to return an error
> string to the user program without such hacks.
Agreed - we could return an 'extended errno' long error return
value, which in reality is a pointer to an error string (in
perf_attr::error_str), and copy that string to user-space at
perf syscall return time.
Thus error-string aware tooling could print the error string.
So PMU drivers could do something obvious like:
return (long)"perf: INST_RETIRED.PREC_DIST only works in exclusive mode";
The perf syscall notices these pointers by noticing that the
error code returned is outside the errno range.
Old userspace will get a -EINVAL and no string copied into the
error string buffer.
New userspace would get the error string copied into
perf_attr::error_str, plus a 'normal' -EINVAL error code.
The only cost on the kernel side is to make sure all "string
errors" are returned as long.
Thanks,
Ingo
next prev parent reply other threads:[~2012-10-21 16:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-19 14:52 [PATCH 0/2] perf: enforce exclusive PMU access for SNB INST_RETIRED:PREC_DIST Stephane Eranian
2012-10-19 14:52 ` [PATCH 1/2] perf tools: add event modifier to request exclusive PMU access Stephane Eranian
2012-10-19 15:13 ` Peter Zijlstra
2012-10-19 15:17 ` Stephane Eranian
2012-10-19 15:23 ` Jiri Olsa
2012-10-19 15:47 ` Stephane Eranian
2012-10-19 15:53 ` Jiri Olsa
2012-10-19 15:58 ` Stephane Eranian
2012-10-19 15:46 ` Andi Kleen
2012-10-19 16:07 ` Jiri Olsa
2012-10-19 14:52 ` [PATCH 2/2] perf: SNB exclusive PMU access for INST_RETIRED:PREC_DIST Stephane Eranian
2012-10-19 15:49 ` Andi Kleen
2012-10-19 15:58 ` Stephane Eranian
2012-10-19 16:27 ` Peter Zijlstra
2012-10-19 16:31 ` Stephane Eranian
2012-10-19 16:45 ` Peter Zijlstra
2012-10-19 17:20 ` Andi Kleen
2012-10-21 16:55 ` Ingo Molnar [this message]
2012-10-21 17:54 ` Stephane Eranian
2012-10-21 18:03 ` Ingo Molnar
2012-10-22 11:31 ` Stephane Eranian
2012-10-24 8:15 ` Ingo Molnar
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=20121021165523.GA29247@gmail.com \
--to=mingo@kernel.org \
--cc=acme@redhat.com \
--cc=ak@linux.intel.com \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.