lkml.org 
[lkml]   [2016]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH RFC v3 1/6] exterr: Introduce extended syscall error reporting
Date
Alexander Shishkin <alexander.shishkin@linux.intel.com> 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

\
 
 \ /
  Last update: 2016-01-11 12:01    [W:0.157 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site