lkml.org 
[lkml]   [2013]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Friendlier EPERM - Request for input
Date
On Sunday 20 January 2013 19:00:46 Eric W. Biederman wrote:
> Carlos O'Donell 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.

the syscall ABI is not the same as the calling convention. pretty much all C
libraries use inline asm to do syscalls. a few applications do too, but for
the most part those have converted to the syscall() library function nowadays
since the kernel stopped exporting _syscall[1-6]() macros for apps to use
directly.

basically, that means you can't change the syscall ABI w/out breaking
userspace especially on i386 as it is the most constrained architecture. you
might get away with it with others which have a lot of spare regs that pretty
much no one uses, but that can be dicey too since you're relying on how code
just happens to be generated by gcc.

the inline asm declares the syscall args only as inputs. the only output is
the return register, and memory/cc are the only clobbers.

you could do this in a backwards compatible way by setting a bit in the
syscall NR to indicate that userland knows it will get back two values. the
kernel will check & clear that bit first before looking up the syscall table.
somewhat like how the x32 ABI is handled.

not saying i like that idea at all, just providing an alternative that would
work w/out breaking userspace.
-mike
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2013-01-21 02:41    [W:0.087 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site