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

> I think that anything other than the errno "grab it now or lose it" > behavior will prove confusing. I don't think there is any other way to > know that a given error report corresponds to a specific system call. > Library calls can mess it up. Kernel changes adding extended reporting to >

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

[Rather belatedly looping in linux-api] On Tue, 15 Sep 2015 18:24:28 +0300 Alexander Shishkin wrote: > Johannes Berg writes: > > > On Tue, 2015-09-15 at 17:15 +0300, Alexander Shishkin wrote: > >> > >> > It seems to me that current->ext_err_code needs to be cleared on > >> > each system

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

Johannes Berg writes: > On Tue, 2015-09-15 at 17:15 +0300, Alexander Shishkin wrote: >> >> > It seems to me that current->ext_err_code needs to be cleared on >> > each system call entry (except for your special prctl() of >> > course!). >> >> I'd say, it should be up to the program to decide

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

On Tue, 2015-09-15 at 17:15 +0300, Alexander Shishkin wrote: > > > It seems to me that current->ext_err_code needs to be cleared on > > each system call entry (except for your special prctl() of > > course!). > > I'd say, it should be up to the program to decide for how long they > want to

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

Jonathan Corbet writes: > So, a couple of comments as I try to figure this stuff out... Thanks for taking the time to look at this. > On Fri, 11 Sep 2015 19:00:00 +0300 > Alexander Shishkin wrote: > >> +int ext_err_copy_to_user(void __user *buf, size_t size) >> +{ >> +struct

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

> I think that anything other than the errno "grab it now or lose it" > behavior will prove confusing. I don't think there is any other way to > know that a given error report corresponds to a specific system call. > Library calls can mess it up. Kernel changes adding extended reporting to >

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

Johannes Berg writes: > On Tue, 2015-09-15 at 17:15 +0300, Alexander Shishkin wrote: >> >> > It seems to me that current->ext_err_code needs to be cleared on >> > each system call entry (except for your special prctl() of >> > course!). >> >> I'd say, it should be

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

[Rather belatedly looping in linux-api] On Tue, 15 Sep 2015 18:24:28 +0300 Alexander Shishkin wrote: > Johannes Berg writes: > > > On Tue, 2015-09-15 at 17:15 +0300, Alexander Shishkin wrote: > >> > >> > It seems to me that

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

Jonathan Corbet writes: > So, a couple of comments as I try to figure this stuff out... Thanks for taking the time to look at this. > On Fri, 11 Sep 2015 19:00:00 +0300 > Alexander Shishkin wrote: > >> +int ext_err_copy_to_user(void __user

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

On Tue, 2015-09-15 at 17:15 +0300, Alexander Shishkin wrote: > > > It seems to me that current->ext_err_code needs to be cleared on > > each system call entry (except for your special prctl() of > > course!). > > I'd say, it should be up to the program to decide for how long they > want to

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

One more little thing: > +int ext_err_copy_to_user(void __user *buf, size_t size) > +{ [...] > +ret = copy_to_user(buf, output, len + 1); > + > +kfree(output); > + > + if (!ret) > + current->ext_err_code = 0; > + > + return ret ? ret : len + 1; > +} I'm

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

On Fri, 11 Sep 2015 19:00:00 +0300 Alexander Shishkin wrote: > 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

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

One more little thing: > +int ext_err_copy_to_user(void __user *buf, size_t size) > +{ [...] > +ret = copy_to_user(buf, output, len + 1); > + > +kfree(output); > + > + if (!ret) > + current->ext_err_code = 0; > + > + return ret ? ret : len + 1; > +} I'm

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

On Fri, 11 Sep 2015 19:00:00 +0300 Alexander Shishkin wrote: > 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

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

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

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

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