Messages in this thread | | | From | (Eric W. Biederman) | Date | Sun, 20 Jan 2013 16:59:35 -0800 | Subject | Re: Friendlier EPERM - Request for input |
| |
ebiederm@xmission.com (Eric W. Biederman) writes:
> Carlos O'Donell <carlos@systemhalted.org> writes: > >> On 01/09/2013 04:09 PM, Eric Paris wrote: >>> On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote: >>>> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote: >>>>> I'm suggesting that the string returned by get_extended_error_info() >>>>> ought to be the audit record the system call would generate, regardless >>>>> of whether the audit system would emit it or not. >>>> >>>> What system call would that info be for and would it be reset on next >>>> syscall that succeeded, or also failed? >>>> >>>> The thing is, various functions e.g. perform some syscall, save errno, do >>>> some other syscall, and if they decide that the first syscall should be what >>>> determines the whole function's errno, just restore errno from the saved >>>> value and return. Similarly, various functions just set errno upon >>>> detecting some error condition in userspace. >>>> There is no 1:1 mapping between many libc library calls and syscalls. >>>> So, when would it be safe to call this new get_extended_error_info function >>>> and how to determine to which syscall it was relevant? >> >> I asked the same questions as Jakub asked but in a slightly different >> formulation (http://cygwin.com/ml/libc-alpha/2013-01/msg00267.html). >> >>> I was thinking of it to be the last kernel error. So if the first and >>> that second operation caused the kernel to want to make available >>> extended errno information you would end up with the second. I see this >>> is an informative piece of information, not normative. Not a >>> replacement for errno. I'm hoping for a best effort way to provide >>> extended errno information. >> >> IMO Casey's answer is the right solution i.e. whatever the errno >> behaviour was. > > Let me propose a different mechanism for getting this to user space > that gives you a save/restore ability. > > When a system call returns with an error we return the error code > in one register and leave the rest of the registers that calling > conventions allow us to stomp unchanged. > > On i386 (probabaly our most constraint architecture) that gives us > 4 32bit registers or 16 bytes/characters to play with. > > Returning either an exteneded error number or a short > string in those extra bytes should be very doable, and largely > backwards compatible. > > Then in userspace for those applications who care you can > have a "struct exteneded_error" that holds the extra information. > > To use that information I expect you want something like: > > char *explain_error(int (*failed_func)(...), int errno, struct extended_error *error);
Hmm. It seems it seems someone else has already written libexplain. http://libexplain.sourceforge.net/
Certainly I would suggest starting there for better explanaitions of why things fail.
If you want good error messages certainly some amount of help from user space appears necessary.
Eric
| |