[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54D52000.40508@zytor.com>
Date: Fri, 06 Feb 2015 12:11:44 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Kees Cook <keescook@...omium.org>,
Andy Lutomirski <luto@...capital.net>
CC: "Dmitry V. Levin" <ldv@...linux.org>,
LKML <linux-kernel@...r.kernel.org>,
Will Drewry <wad@...omium.org>,
Oleg Nesterov <oleg@...hat.com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Linux MIPS Mailing List <linux-mips@...ux-mips.org>,
linux-arch <linux-arch@...r.kernel.org>,
linux-security-module <linux-security-module@...r.kernel.org>,
Alexei Starovoitov <ast@...mgrid.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Michael Kerrisk-manpages <mtk.manpages@...il.com>
Subject: Re: [PATCH v5 3/5] x86: Split syscall_trace_enter into two phases
On 02/06/2015 11:23 AM, Kees Cook wrote:
>
> Strictly speaking (ISO C, "man 3 errno"), errno is supposed to be a
> full int, though digging around I find this in include/linux/err.h:
>
That doesn't mean the kernel has to support them.
> /*
> * Kernel pointers have redundant information, so we can use a
> * scheme where we can return either an error code or a normal
> * pointer with the same return value.
> *
> * This should be a per-architecture thing, to allow different
> * error and pointer decisions.
> */
> #define MAX_ERRNO 4095
>
> #ifndef __ASSEMBLY__
>
> #define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
>
> But no architecture overrides this.
>
We used to have a much lower value, that was per-architecture, in order
to optimize the resulting assembly (e.g. 8-bit immediates on x86). This
didn't work as the number of errnos increased. The other motivation was
probably binary compatibility with other Unices, which was an idea for a
while.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists