Re: [PATCH RFC v3 1/6] exterr: Introduce extended syscall error reporting

From: Alexander Shishkin
Date: Mon Jan 11 2016 - 05:34:22 EST


Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx> 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