From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759380AbcAKKeT (ORCPT ); Mon, 11 Jan 2016 05:34:19 -0500 Received: from mga03.intel.com ([134.134.136.65]:15764 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758798AbcAKKeS (ORCPT ); Mon, 11 Jan 2016 05:34:18 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,552,1444719600"; d="scan'208";a="858045192" From: Alexander Shishkin To: Peter Zijlstra , Ingo Molnar Cc: linux-kernel@vger.kernel.org, vince@deater.net, eranian@google.com, johannes@sipsolutions.net, Arnaldo Carvalho de Melo Subject: Re: [PATCH RFC v3 1/6] exterr: Introduce extended syscall error reporting In-Reply-To: <1441987205-4021-2-git-send-email-alexander.shishkin@linux.intel.com> References: <1441987205-4021-1-git-send-email-alexander.shishkin@linux.intel.com> <1441987205-4021-2-git-send-email-alexander.shishkin@linux.intel.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Mon, 11 Jan 2016 12:34:14 +0200 Message-ID: <87d1t89zh5.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Alexander Shishkin writes: > It has been pointed out several times that certain system calls' error > reporting leaves a lot to be desired [1], [2]. Such system calls would > take complex parameter structures as their input and return -EINVAL if > one or more parameters are invalid or in conflict leaving it up to the > user to figure out exactly what is wrong with their request. One such > syscall is perf_event_open() with its attribute structure containing > 40+ parameters and tens of parameter validation checks. > > This patch introduces a fairly simple infrastructure that allows call > sites to annotate their error codes with arbitrary strings, which the > userspace can fetch using a prctl() along with the module name that > produced the error message, file name, line number and optionally any > amount of additional information in JSON format. This way, we can > provide both human-readable and machine-parsable information to user and > leave room for domain-specific extensions, such as the field in the > parameter structure that caused the error. > > Each error "site" is referred to by its index, which is folded into an > integer error value within the range of [-EXT_ERRNO, -MAX_ERRNO], where > EXT_ERRNO is chosen to be below any known error codes, but still leaving > enough room to enumerate error sites. This way, all the traditional macros > will still handle these as error codes and we'd only have to convert them > to their original values right before returning to userspace. At that > point we'd also store a pointer to the error descriptor in the task_struct, > so that a subsequent prctl() call can retrieve it. > > [1] http://marc.info/?l=linux-kernel&m=141470811013082 > [2] http://marc.info/?l=linux-kernel&m=144049385530680 Ingo, how do you feel about moving this in the more generalized direction like this or would you say I should give up and keep it perf specific? Because there seems to be demand for it in the perf land. Regards, -- Alex