Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751907AbbH1KHx (ORCPT ); Fri, 28 Aug 2015 06:07:53 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:35234 "EHLO mail-wi0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751688AbbH1KHd (ORCPT ); Fri, 28 Aug 2015 06:07:33 -0400 Date: Fri, 28 Aug 2015 12:07:28 +0200 From: Ingo Molnar To: Andrew Morton Cc: Peter Zijlstra , Johannes Berg , Linus Torvalds , Thomas Gleixner , adrian.hunter@intel.com, Ingo Molnar , Borislav Petkov , Vince Weaver , Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, Alexander Shishkin , "H. Peter Anvin" , Stephane Eranian Subject: Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting Message-ID: <20150828100728.GA23517@gmail.com> References: <20150825100728.GA1820@gmail.com> <1440497981.2192.39.camel@sipsolutions.net> <20150826044948.GC14584@gmail.com> <1440572775.1932.1.camel@sipsolutions.net> <20150826072020.GA19081@gmail.com> <20150826072656.GA19305@gmail.com> <20150826114111.01675d8eadda78d82933d8a5@linux-foundation.org> <20150826200513.GX16853@twins.programming.kicks-ass.net> <20150826132249.fbb2aa602525c7df4a1f86ed@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150826132249.fbb2aa602525c7df4a1f86ed@linux-foundation.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3324 Lines: 78 * Andrew Morton wrote: > On Wed, 26 Aug 2015 22:05:13 +0200 Peter Zijlstra 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. So the perf background was well understood by most people involved, it just didn't survive into the 0/N description: The problem is that we have a complex attribute structure with dozens of user triggerable (and often hardware dependent) failure scenarios all returning one of -EINVAL or -ENOTSUPP. Likewise there's a similarly complex scheduler attribute structure handled by SyS_sched_setattr() with 10+ failure modes. So since the kernel actually knows exactly what the failure was, and we lose that information due to errno clustering, we thought it brilliant idea to try to be helpful to human users of the tooling and to attempt to preserve this information - to make Linux tooling a bit less passive-aggressive than it is today. (Or at least those parts of tooling that we are writing!) The other option would be to replicate all the failure analysis in user-space - which sucks and which it cannot even do in some important cases. The third option is to maintain the status quo: let Linux tooling continue to suck wrt. failure analysis. > Also... we're talking only of perf, so perhaps some perf-specific reporting > scheme would be better, rather than a kernel-wide thing. That was indeed the starting point, at which point scheduler syscalls came up, and potentially other places in the kernel were mentioned, so we thought we'd try to be more generally useful. To address the inevitable "why did you code this up in a perf-specific way??!" complaints and such ;-) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/