Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752135AbbHZEty (ORCPT ); Wed, 26 Aug 2015 00:49:54 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:37503 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750794AbbHZEtx (ORCPT ); Wed, 26 Aug 2015 00:49:53 -0400 Date: Wed, 26 Aug 2015 06:49:48 +0200 From: Ingo Molnar To: Johannes Berg Cc: Alexander Shishkin , Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, adrian.hunter@intel.com, Arnaldo Carvalho de Melo , Vince Weaver , Stephane Eranian , Linus Torvalds , Andrew Morton , Thomas Gleixner , Borislav Petkov , "H. Peter Anvin" Subject: Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting Message-ID: <20150826044948.GC14584@gmail.com> References: <1440426780-27227-1-git-send-email-alexander.shishkin@linux.intel.com> <1440492739.2192.7.camel@sipsolutions.net> <20150825090252.GB22414@gmail.com> <20150825091740.GA23488@gmail.com> <1440495246.2192.13.camel@sipsolutions.net> <20150825100728.GA1820@gmail.com> <1440497981.2192.39.camel@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1440497981.2192.39.camel@sipsolutions.net> 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: 4265 Lines: 93 * Johannes Berg wrote: > On Tue, 2015-08-25 at 12:07 +0200, Ingo Molnar wrote: > > Having a separate syscall has two (big!) appeals: > > > > - we wouldn't have to touch existing system calls at all. > > > > - extended error reporting would be available for any system call that opts to > > use it. (The current scheme as submitted is only available to system calls > > using the perf-style flexible attribute ABI.) > > Yeah, I agree this is nice. However, more generally, I think we need to > actually think more about the module problem then since while syscalls > can't be implemented in modules (I think) they can still end up calling > into modules. > > Of course a first iteration could be exactly like what Alexander > posted. > > The other issue with this is namespacing - can all syscalls, and > everything that eventually gets called, really use a single error code > namespace with its 3k limit? [...] No, the current MAX_ERRNO is probably not big enough if this scheme is successful, and I don't see any reason why it wouldn't be successful: I think this feature would be the biggest usability feature added to Linux system calls and to Linux system tooling in the last 10 years or so. > [...] On the one hand I'm thinking "3k strings are so big ... we don't want > more", but on the other hand all kinds of drivers etc. might start getting > annotations? We could extend it with some arch work. The per arch work involves making sure there's no valid kernel address at [-MAX_ERRNO...-1]. So I wouldn't worry about it too much, let's agree on a good ABI and let's just start using it, and if we grow out of -4K we can extend things step by step. > > Ok. So assuming we can make a 1:1 mapping between the 'extended error code' > > integer space and the message:owner strings, it would be enough for netlink to > > pass along the integer code itself, not the full strings? > > Considering that this would likely have to be opt-in at the netlink level (e.g. > through a flag in the request message), perhaps. I'd say it'd still be easier > for the message to carry the intended error code (e.g. -EINVAL) and the actual > message in the ACK message [where requested]. That way, applications that > actually behave depending on the error code can far more easily be extended. Ok. I think we should include the extended error code as well, in case an app wants to pass it to some more generic library. > > That would simplify things and make the scheme more robust from a security POV > > I suspect. > > You could also argue the other way around, in that being able to look up (from > userspace) arbitrary extended error IDs, even those that haven't ever been used, > could be an information leak of sorts. The fact is that kernel<->tooling error reporting sucks big time here and today, in large part due to errno limitations, and arguing that it's somehow helping security is the Stockholm Syndrome at its best. > > So my hope would be that we can represent this all with a single 'large' error > > code integer space. That integer would be constant and translateable (as long > > as the module is loaded). > > Ok, I wasn't really what I was assuming. As I said above, on the one > hand I agree, but on the other I'm looking at the reality of a few > hundred (!) -EINVAL callsites in net/wireless/nl80211.c alone, so > having an overall 3k limit seems somewhat low. Agreed - but it's not a hard limit really. > > That way the error passing mechanism wouldn't have to be specifically > > module-aware - during build we generate the integer space, with all possible > > modules considered. > > That would be no improvement for me as I work heavily with (upstream) modules > that are compiled out-of-tree, so I'm not all inclined to spend much time on it > if that ends up being the solution ;) Perhaps, as long as the number allocation is dynamic and non-ABI there's no reason why this couldn't be added later on. 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/