[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMzpN2gqgSASSDR2e_5PPNFgQSvcdFtDnCBVx5-UcVEVSifLbQ@mail.gmail.com>
Date: Wed, 18 Oct 2017 07:30:08 -0700
From: Brian Gerst <brgerst@...il.com>
To: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"the arch/x86 maintainers" <x86@...nel.org>,
Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH] x86, syscalls: use SYSCALL_DEFINE() macros for sys_modify_ldt()
On Tue, Oct 17, 2017 at 12:22 PM, Dave Hansen
<dave.hansen@...ux.intel.com> wrote:
>
> We do not have tracepoints for sys_modify_ldt() because we define
> it directly instead of using the normal SYSCALL_DEFINEx() macros.
>
> However, there is a reason sys_modify_ldt() does not use the macros:
> it has an 'int' return type instead of 'unsigned long'. This is
> a bug, but it's a bug cemented in the ABI.
>
> What does this mean? If we return -EINVAL from a function that
> returns 'int', we have 0x00000000ffffffea in %rax. But, if we
> return -EINVAL from a function returning 'unsigned long', we end
> up with 0xffffffffffffffea in %rax, which is wrong.
>
> To work around this and maintain the 'int' behavior while using
> the SYSCALL_DEFINEx() macros, so we add a cast to 'unsigned int'
> in both implementations of sys_modify_ldt().
Reviewed-by: Brian Gerst <brgerst@...il.com>
Powered by blists - more mailing lists