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@xxxxxxxxxxxxxxx> wrote:

> Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/