Messages in this thread | | | From | Alexander Shishkin <> | Subject | Re: [PATCH RFC v3 1/6] exterr: Introduce extended syscall error reporting | Date | Mon, 11 Jan 2016 12:34:14 +0200 |
| |
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
| |