global errno considered harmful
RFC PATCH 1/1 global errno considered harmful
Hi,
Is there any particular reason we need a global errno in the kernel at all? (which, by the way, doesn't seem to be subject to any kind of locking) It makes life for User Mode Linux somewhat more complicated than it could be, and it generally just seems a bad idea. Half a dozen places in the kernel call syscalls from kernel space (the asm/unistd.h __KERNEL_SYSCALLS__ stubs), but it sounds way better to change that limited number to check the syscall return code instead of errno.
It appears that only one syscall stub caller checks syscall return value anyway (exec_usermodehelper in kernel/kmod.c), so removing errno is quite painless. Referenced patch deletes all mention of a global errno from the kernel, and fixes up callers where necessary. I had to change definition of _syscallX in various asm/unistd.h's not to use errno which might break some userland, but userland shouldn't be touching these anyway.
Only tested on i386. Feedback appreciated, particularly experiences on non-i386.
http://www.math.leidenuniv.nl/~buytenh/errno_ectomy-1.diff (33kb)
cheers,
Lennert
Quoted 3 lines · [email protected] said:
Is there any particular reason we need a global errno in the kernel at all? (which, by the way, doesn't seem to be subject to any kind of locking)
As far as I've been able to tell, no.
Quoted 2 lines
It makes life for User Mode Linux somewhat more complicated than it could be, and it generally just seems a bad idea.
Yeah. In order for -fno-common to not blow up the UML build (because of the clash between libc errno and kernel errno), I had to add -Derrno=kernel_errno to all the kernel file compiles. It would be nice to get rid of that wart.
Quoted 2 lines
Referenced patch deletes all mention of a global errno from the kernel
Awesome. This definitely needs to happen. If no one spots any breakage, send it in...
Quoted 1 line
and fixes up callers where necessary.
I did some grepping and the only problem I noticed was UML's execve (heh) converting a -errno return to a -1.
Jeff
And can anybody explain, why is it so ?
(I mean checking for -1, and the switch(errno){}.) AFAIK, syscall returns us a number (on i386 it is in eax) and we can use it. Is errno a kernel thing, or GLIBC ?
Haven't we a return code in eax, after int 0x80 ?
(sorry, but I never worked on Linux on other architectures)
Best regards.
Quoted 2 lines · Lennert Buytenhek
Is there any particular reason we need a global errno in the kernel at all? (which, by the way, doesn't seem to be subject to any kind of
Quoted 6 lines · Jeff Dike
Quoted 3 lines · [email protected] said:
Is there any particular reason we need a global errno in the kernel at all? (which, by the way, doesn't seem to be subject to any kind of locking)
As far as I've been able to tell, no.
Historically the reason was to make unistd.h usable from userspace. Which is causing tremendous portability problems so apps better shouldn't think about using the syscall interface directly.
Quoted 7 lines
Quoted 2 lines
It makes life for User Mode Linux somewhat more complicated than it could be, and it generally just seems a bad idea.
Yeah. In order for -fno-common to not blow up the UML build (because of the clash between libc errno and kernel errno), I had to add -Derrno=kernel_errno to all the kernel file compiles. It would be nice to get rid of that wart.
Quoted 5 lines
Quoted 2 lines
Referenced patch deletes all mention of a global errno from the kernel
Awesome. This definitely needs to happen. If no one spots any breakage, send it in...
As user application are trying to use unistd.h and expect errno to get set properly unistd.h or at least it's syscallX macros will have to be made unusable from userspace or silent breakage of such apps rebuild against new headers will occur.
Ralf
Quoted 24 lines · Ralf Baechle
Quoted 6 lines · Jeff Dike
Quoted 3 lines · [email protected] said:
Is there any particular reason we need a global errno in the kernel at all? (which, by the way, doesn't seem to be subject to any kind of locking)
As far as I've been able to tell, no.
Historically the reason was to make
unistd.husable from userspace. Which is causing tremendous portability problems so apps better shouldn't think about using the syscall interface directly.Quoted 10 lines
Quoted 2 lines
It makes life for User Mode Linux somewhat more complicated than it could be, and it generally just seems a bad idea.
Yeah. In order for -fno-common to not blow up the UML build (because of the clash between libc errno and kernel errno), I had to add -Derrno=kernel_errno to all the kernel file compiles. It would be nice to get rid of that wart.
Quoted 2 lines
Referenced patch deletes all mention of a global errno from the kernel
Quoted 7 lines
Quoted 2 lines
Awesome. This definitely needs to happen. If no one spots any breakage, send it in...
As user application are trying to use
unistd.hand expect errno to get set properlyunistd.hor at least it's syscallX macros will have to be made unusable from userspace or silent breakage of such apps rebuild against new headers will occur.
Userspace should be using glibc's unistd.h. If it's using the kernel's, it's broken.
--
Brian Gerst
Quoted 4 lines · Ralf Baechle
As user application are trying to use
unistd.hand expect errno to get set properlyunistd.hor at least it's syscallX macros will have to be made unusable from userspace or silent breakage of such apps rebuild against new headers will occur.
How about conditionalising definition of_syscallX on __KERNEL_SYSCALLS__?
(http://www.math.leidenuniv.nl/~buytenh/errno_ectomy-1-to-2.diff)
I guess I'll go ask all arch maintainers' permission now..
cheers,
Lennert
Quoted 7 lines · Brian Gerst
Quoted 4 lines
As user application are trying to use
unistd.hand expect errno to get set properlyunistd.hor at least it's syscallX macros will have to be made unusable from userspace or silent breakage of such apps rebuild against new headers will occur.Userspace should be using glibc's
unistd.h. If it's using the kernel's, it's broken.
A sufficient number take the unavailability of new syscall in everybody's glibc as a sufficient excuse for broken code. util-linux as a major offender comes to mind or also e2fsprogs.
Ralf
Quoted 9 lines · Lennert Buytenhek
Quoted 4 lines
As user application are trying to use
unistd.hand expect errno to get set properlyunistd.hor at least it's syscallX macros will have to be made unusable from userspace or silent breakage of such apps rebuild against new headers will occur.How about conditionalising definition
of_syscallXon__KERNEL_SYSCALLS__?(http://www.math.leidenuniv.nl/~buytenh/errno_ectomy-1-to-2.diff)I guess I'll go ask all arch maintainers' permission now..
Be careful, you'll have to fix at least util-linux (doubleplusyuck) and e2fsprogs.
Ralf
Ralf Baechle <[email protected]> writes:
|> On Sun, Dec 30, 2001 at 05:10:41PM -0500, Brian Gerst wrote: |> |> > > As user application are trying to use unistd.h and expect errno to get |> > > set properly unistd.h or at least it's syscallX macros will have to be |> > > made unusable from userspace or silent breakage of such apps rebuild |> > > against new headers will occur. |> > |> > Userspace should be using glibc's unistd.h. If it's using the kernel's, |> > it's broken. |> |> A sufficient number take the unavailability of new syscall in everybody's |> glibc as a sufficient excuse for broken code. util-linux as a major |> offender comes to mind or also e2fsprogs.
Userspace should be using syscall(2/3) for new syscalls.
Andreas.
Signature · 4 lines
Andreas Schwab "And now for something [email protected] completely different." SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
Quoted 7 lines · Ralf Baechle
Quoted 5 lines · Lennert Buytenhek
Quoted 4 lines
As user application are trying to use
unistd.hand expect errno to get set properlyunistd.hor at least it's syscallX macros will have to be made unusable from userspace or silent breakage of such apps rebuild against new headers will occur.
Quoted 7 lines
Quoted 4 lines
How about conditionalising definition
of_syscallXon__KERNEL_SYSCALLS__?(http://www.math.leidenuniv.nl/~buytenh/errno_ectomy-1-to-2.diff)I guess I'll go ask all arch maintainers' permission now..
Be careful, you'll have to fix at least util-linux (doubleplusyuck) and e2fsprogs.
You say this as if having util-linux and e2fsprogs etc get fixed would be a bad thing... I personally think this would be a very good change, and would let the kernel enforce good programming style,
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Quoted 5 lines · Andreas Schwab
|> A sufficient number take the unavailability of new syscall in everybody's |> glibc as a sufficient excuse for broken code. util-linux as a major |> offender comes to mind or also e2fsprogs.Userspace should be using syscall(2/3) for new syscalls.
Which just replaces one problem with another, slightly smaller one. So something like syscall(SYS_pwrite, fd, buf, count, pos) will not work on all architectures because pos is a 64-bit argument which as to be passed in an aligned register pair on some machines, so an additional argument has to be inserted. So the glorious attempt to use syscall() will now write data to fantasy positions in a file. Great. And just an example demonstrating that the syscall interface is seriously dangerous and non-portable. I don't think there is anyway except people limiting themselfes APIs provided by libc or similar but not using syscalls directly.
Ralf