From: Andrew Morton <akpm@linux-foundation.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>,
Johannes Berg <johannes@sipsolutions.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
adrian.hunter@intel.com, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>, Vince Weaver <vince@deater.net>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
linux-kernel@vger.kernel.org,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting
Date: Wed, 26 Aug 2015 13:22:49 -0700 [thread overview]
Message-ID: <20150826132249.fbb2aa602525c7df4a1f86ed@linux-foundation.org> (raw)
In-Reply-To: <20150826200513.GX16853@twins.programming.kicks-ass.net>
On Wed, 26 Aug 2015 22:05:13 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
> > Is this whole thing overkill? As far as I can see, the problem which is
> > being addressed only occurs in a couple of places (perf, wifi netlink
> > handling) and could be addressed with some local pr_debug statements. ie,
> >
> > #define err_str(e, s) ({
> > if (debugging)
> > pr_debug("%s:%d: error %d (%s)", __FILE__, __LINE__, e, s);
> > e;
> > })
> >
> > (And I suppose that if this is later deemed inadequate, err_str() could
> > be made more fancy).
>
> Not really. That is something that's limited to root. Whereas the
> problem is very much wider than that.
>
> If you set one bit wrong in the pretty large perf_event_attr you've got
> a fair chance of getting -EINVAL on trying to create the event. Good
> luck finding what you did wrong.
>
> Any user can create events (for their own tasks), this does not require
> root.
>
> Allowing users to flip your @debugging flag would be an insta DoS.
>
> Furthermore, its very unfriendly in that you have to (manually) go
> correlate random dmesg output with some program action.
It depends on who the audience is. If it's developers who are writing
userspace perf tooling then all the above won't be an issue. If it's
aimed at end users of that tooling then yes.
IOW, we're in the usual situation of discussing implementation before
anyone has explained the requirements.
Also... we're talking only of perf, so perhaps some perf-specific
reporting scheme would be better, rather than a kernel-wide thing.
next prev parent reply other threads:[~2015-08-26 20:22 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-24 14:32 Alexander Shishkin
2015-08-24 14:32 ` [PATCH v2 1/6] " Alexander Shishkin
2015-08-31 18:47 ` Andy Shevchenko
2015-09-01 6:38 ` Alexander Shishkin
2015-08-24 14:32 ` [PATCH v2 2/6] perf: Add file name and line number to perf extended error reports Alexander Shishkin
2015-08-24 14:32 ` [PATCH v2 3/6] perf: Annotate some of the error codes with perf_err() Alexander Shishkin
2015-08-24 14:32 ` [PATCH v2 4/6] perf/x86: " Alexander Shishkin
2015-08-24 14:32 ` [PATCH v2 5/6] perf/x86/intel/pt: Use extended error reporting in event initialization Alexander Shishkin
2015-08-24 14:33 ` [PATCH v2 6/6] perf/x86/intel/bts: " Alexander Shishkin
2015-08-25 8:22 ` [PATCH v2 0/6] perf: Introduce extended syscall error reporting Ingo Molnar
2015-08-25 8:52 ` Johannes Berg
2015-08-25 9:02 ` Ingo Molnar
2015-08-25 9:17 ` Ingo Molnar
2015-08-25 9:34 ` Johannes Berg
2015-08-25 10:07 ` Ingo Molnar
2015-08-25 10:19 ` Johannes Berg
2015-08-26 4:49 ` Ingo Molnar
[not found] ` <CA+55aFw--OFczoY=v17+e2-Q3O0GXnMKRuwzpYpB2qKBpZo=fw@mail.gmail.com>
2015-08-26 7:02 ` Ingo Molnar
2015-08-26 7:06 ` Johannes Berg
2015-08-26 7:20 ` Ingo Molnar
2015-08-26 7:26 ` Ingo Molnar
2015-08-26 16:56 ` Alexander Shishkin
2015-08-26 20:58 ` Arnaldo Carvalho de Melo
2015-09-11 16:11 ` Alexander Shishkin
2015-08-26 18:41 ` Andrew Morton
2015-08-26 20:05 ` Peter Zijlstra
2015-08-26 20:22 ` Andrew Morton [this message]
2015-08-26 20:50 ` Vince Weaver
2015-08-26 20:56 ` Andrew Morton
2015-08-26 21:14 ` Vince Weaver
2015-08-28 10:07 ` Ingo Molnar
2015-08-26 21:04 ` Arnaldo Carvalho de Melo
2015-08-26 7:36 ` Johannes Berg
2015-08-26 11:37 ` Alexander Shishkin
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=20150826132249.fbb2aa602525c7df4a1f86ed@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=acme@infradead.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=eranian@google.com \
--cc=hpa@zytor.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vince@deater.net \
/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
Powered by JetHome