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

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

[Jonathan Corbet]

[Rather belatedly looping in linux-api]

On Tue, 15 Sep 2015 18:24:28 +0300
Alexander Shishkin <alexander.shishkin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:

> Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> 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 for how long they 
> >> want to keep the extended error code around.
> >>   
> >
> > I'm not convinced that works - imagine a library wanting to use the
> > prctl(), but the main application isn't doing that. Should the library
> > clear it before every call, to be sure it's not getting stale data?
> > etc.  
> 
> In other words, a syscall that's capable of throwing an extended error
> does clear the current::ext_err_code every time, but not other
> syscalls. Otherwise it will indeed get very confusing.

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
new system calls can mess it up.  Applications cannot possibly be expected
to know which system calls might change the error-reporting status, they
*have* to assume all of them will.

Or so it seems to me, anyway...

jon

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

[Johannes Berg]

> 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
> new system calls can mess it up.  Applications cannot possibly be expected
> to know which system calls might change the error-reporting status, they
> *have* to assume all of them will.
> 

Yeah I was about to say something similar - an application that expects
a certain syscall to have extended errors will get confused if running
on an older kernel where that syscall in fact does *not* have extended
errors (and thus also doesn't clear extended errors) and therefore the
extended error from a previous syscall could still be lingering on (for
example because the application didn't care to fetch it for that previo
us syscall.)

johannes