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 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. It would be really neat for libc to have a way to save and restore the extended errno information, maybe even supply its own if it made the choice in userspace, but that sounds really hard for the first pass. I mean it would be great if we could rewrite every system call with a cookie so userspace could reliably match things back up, but I just don't see that as practical. Instead we do the best we can and help admins and developers most of the time, instead of none of the time. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
