linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Stephane Eranian <eranian@google.com>
Cc: Andi Kleen <ak@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	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 20:03:41 +0200	[thread overview]
Message-ID: <20121021180341.GA4128@gmail.com> (raw)
In-Reply-To: <CABPqkBR_BSf6Akzxn+2gOrksUMXmAgPi3xY0KJUbhT0Eddo3Kw@mail.gmail.com>


* Stephane Eranian <eranian@google.com> wrote:

> On Sun, Oct 21, 2012 at 6:55 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * 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.
> >
> I assume by perf_attr:error_str, you actually mean:
> 
> struct perf_event_attr {
>    char error_str[PERF_ERR_LEN];
> };
> 
> Right?

I don't think we should allocate space in the attr, instead we 
should use something like:

	u8 __user	*err_str;
	u32		 err_str_len;

which would be filled in by tooling with a string and a max_len 
value, and strncpy_to_user() could do the rest on the kernel 
side. [ A minor complication is that we don't have a 
strncpy_to_user() method at the moment. ]

Static strings could be handled this way.

[ Dynamic strings could be supported too with a few tricks, 
  although I doubt it matters in practice. ]

> > 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.
>
> Is that always the case on all archs?

I think yes - and if not then it can be solved via some trivial 
offset value added to it on such an architecture, without 
complicating the code on normal architectures.

Thanks,

	Ingo

  reply	other threads:[~2012-10-21 18:03 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
2012-10-21 17:54             ` Stephane Eranian
2012-10-21 18:03               ` Ingo Molnar [this message]
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=20121021180341.GA4128@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).